Re: svnmucc: new commands: add and modify/update
On Fri, 24 Jul 2020 at 07:06, Daniel Shahaf wrote: > > Daniel Sahlberg wrote on Fri, 24 Jul 2020 05:53 +00:00: > > Den fre 24 juli 2020 01:46sebb skrev: > > > I am suggesting that 'add' functionality could be added to svnmucc itself. > > > This would make it more versatile, especially for use in shell scripts. > > > > Unless I'm mistaken, add is a purely local action within a working > > copy. And the point with svnmucc is that you work with a repository > > without having a wc. How should add work with svnmucc? > > It would work exactly like «svnmucc put $dirent $URL», except that it > would fail if $URL already exists, similar to open(O_EXCL) in C. Yes, please! Note that svn add is indeed local, but the commit will fail if the remote file exists.
Re: svnmucc: new commands: add and modify/update
Daniel Sahlberg wrote on Fri, 24 Jul 2020 05:53 +00:00: > Den fre 24 juli 2020 01:46sebb skrev: > > I am suggesting that 'add' functionality could be added to svnmucc itself. > > This would make it more versatile, especially for use in shell scripts. > > Unless I'm mistaken, add is a purely local action within a working > copy. And the point with svnmucc is that you work with a repository > without having a wc. How should add work with svnmucc? It would work exactly like «svnmucc put $dirent $URL», except that it would fail if $URL already exists, similar to open(O_EXCL) in C.
Re: svnmucc: new commands: add and modify/update
Den fre 24 juli 2020 01:46sebb skrev: > I am suggesting that 'add' functionality could be added to svnmucc itself. > This would make it more versatile, especially for use in shell scripts. > Unless I'm mistaken, add is a purely local action within a working copy. And the point with svnmucc is that you work with a repository without having a wc. How should add work with svnmucc? Kind regards Daniel Sahlberg >
Re: svnmucc: new commands: add and modify/update
On Thu, 23 Jul 2020 at 23:44, Daniel Shahaf wrote: > > sebb wrote on Thu, 23 Jul 2020 11:30 +0100: > > On Thu, 23 Jul 2020 at 00:59, Daniel Shahaf wrote: > > > > > > sebb wrote on Wed, 22 Jul 2020 22:44 +0100: > > > > The SVN put command can add a new file or update an existing one. > > > > > > > > As part of a batch update it may be necessary to ensure that a > > > > particular file will be created and not updated - or vice versa. > > > > That is currently not at all easy to do, which is a shame as svnmucc > > > > is otherwise very useful for writing atomic updates that are not > > > > possible with the svn client. > > > > > > What can svnmucc(1) do that svn(1) can't? > > > > Atomic updates. > > > > AIUI an svnmucc script only succeeds if all the individual commands succeed. > > > > To do that with single commands would require reversion and/or retries. > > > > If the reason for an svn client failure is a network or server issue, > > it's going to be very difficult to tidy up. > > You're describing CVS, not Subversion. No: I'm not referring to tidying up the repository itself, but the application level inconsistency that can result if a related sequence of svn commits does not complete. The issue I am trying to solve is how to ensure related changes to a subversion repository either all occur or none do. For example, adding a new file to a directory, and updating a listing with details of that file. The file must not already exist. The listing is in a different part of the repository. Whilst it would probably be possible to create a sparse checkout of the different parts of the repository, this is not trivial. It seems like an ideal job for svnmucc. However svnmucc does not directly support svn 'add' functionality. Whilst this can also be worked round, it is quite tedious and easy to get wrong. I am suggesting that 'add' functionality could be added to svnmucc itself. This would make it more versatile, especially for use in shell scripts. (*) I am referring to application-level consistency here, not consistency of the repository itself.
Re: svnmucc --revision 0 no longer works when creating a file
sebb wrote on Thu, 23 Jul 2020 11:18 +0100: > On Thu, 23 Jul 2020 at 01:17, Daniel Shahaf wrote: > > You can either parse stderr despite this complication, or use the > > API directly, in which case you'll sidestep this complication entirely > > (you'll get just one integer, rather than two). > > What API are you referring to here? The C API or the various language bindings, bypassing the cmdline client.
Re: svnmucc: new commands: add and modify/update
sebb wrote on Thu, 23 Jul 2020 11:30 +0100: > On Thu, 23 Jul 2020 at 00:59, Daniel Shahaf wrote: > > > > sebb wrote on Wed, 22 Jul 2020 22:44 +0100: > > > The SVN put command can add a new file or update an existing one. > > > > > > As part of a batch update it may be necessary to ensure that a > > > particular file will be created and not updated - or vice versa. > > > That is currently not at all easy to do, which is a shame as svnmucc > > > is otherwise very useful for writing atomic updates that are not > > > possible with the svn client. > > > > What can svnmucc(1) do that svn(1) can't? > > Atomic updates. > > AIUI an svnmucc script only succeeds if all the individual commands succeed. > > To do that with single commands would require reversion and/or retries. > > If the reason for an svn client failure is a network or server issue, > it's going to be very difficult to tidy up. You're describing CVS, not Subversion.
Re: svnmucc: new commands: add and modify/update
On Thu, 23 Jul 2020 at 00:59, Daniel Shahaf wrote: > > sebb wrote on Wed, 22 Jul 2020 22:44 +0100: > > The SVN put command can add a new file or update an existing one. > > > > As part of a batch update it may be necessary to ensure that a > > particular file will be created and not updated - or vice versa. > > That is currently not at all easy to do, which is a shame as svnmucc > > is otherwise very useful for writing atomic updates that are not > > possible with the svn client. > > What can svnmucc(1) do that svn(1) can't? Atomic updates. AIUI an svnmucc script only succeeds if all the individual commands succeed. To do that with single commands would require reversion and/or retries. If the reason for an svn client failure is a network or server issue, it's going to be very difficult to tidy up. > > Would there be any support for extending svnmucc to add these operations? > > Either as options to put, or as separate commands. > > The standard solutions for your situation are: > > 1. > - Get HEAD's value as an integer > - Check file existence/inexistence in that revision > - Run 'svnmucc -r' > > 2. > svn co --depth=empty $URL wc > svn up --set-depth=infinity wc/foo > ⋮ > # (as posted in > https://mail-archives.apache.org/mod_mbox/subversion-users/202007.mbox/%3C20200712142604.128f80eb%40tarpaulin.shahaf.local2%3E) > > In what ways do they fall short? >
Re: svnmucc --revision 0 no longer works when creating a file
On Thu, 23 Jul 2020 at 01:17, Daniel Shahaf wrote: > > sebb wrote on Wed, 22 Jul 2020 22:34 +0100: > > On Wed, 22 Jul 2020 at 17:46, Nathan Hartman > > wrote: > > > > > > On Wed, Jul 22, 2020 at 12:10 PM sebb wrote: > > > > > Use the machine-parseable E42 error codes. That's exactly what > > > > > they're for. (which-error.py and svn_error_symbolic_name() can be > > > > > used > > > > > to convert numbers to symbolic names.) > > > > > > > > Where are these error codes defined? > > > > I could not find any reference to them in the documentation. > > > > > > If you mean where in the source code: > > > > > > subversion/include/svn_error_codes.h > > > which is included by subversion/include/svn_error.h, which is further > > > included by subversion/svnmucc/svnmucc.c. > > > > > > Hope that helps, > > > > Thanks, but not really. > > > > If the error codes are intended to be machine-parseable then the > > programmer needs to have documentation of the values and their > > meanings. > > There needs to be at least a mention in the documentation that such > > codes exist and where to find the values. If there is such a mention, > > I could not find it. > > Doxygen docs of svn_error_t::apr_err. But how does one find that information? > > Also, I had a look at the file and it does not show the numeric > > values, > > I refer you again to which-error.py. Again, how is one supposed to know about this script? Also, I assume this requires Python. > > and whilst there is a text string associated with each one it > > does not detail when it might be used. > > Nor indeed do the strings agree with the actual messages generated by > > SVN as far as I can tell. > > No, they don't. The strings in that file are defaults, only used when > the line of code that raised an error didn't provide a more specific > string. > > > e.g. svn list reports the following: > > > > svn: warning: W160013: Path '/x' not found > > svn: E29: Could not list all targets because some targets don't exist > > Great. Run which-error.py on this and you'll find that the former code > is SVN_ERR_FS_NOT_FOUND. That's basically the svn API equivalent of > ENOENT, i.e., "There's no node by that name in the versioned > filesystem". Therefore, you'll want to write your script to handle > E160013 errors by ignoring them and continuing. I would need to know whether E29 can only be produced when a target does not exist. Otherwise it might look like the file does not exist when it does. > The complication here is that `svn list` supports multiple target > arguments, and has to handle the case that some but not all of them are > invalid. It does so by reporting the errors from individual targets as > W* codes rather than E* codes and adding a generic E29 error at the > end. You can either parse stderr despite this complication, or use the > API directly, in which case you'll sidestep this complication entirely > (you'll get just one integer, rather than two). What API are you referring to here? > Daniel
Re: svnmucc --revision 0 no longer works when creating a file
sebb wrote on Wed, 22 Jul 2020 22:34 +0100: > On Wed, 22 Jul 2020 at 17:46, Nathan Hartman wrote: > > > > On Wed, Jul 22, 2020 at 12:10 PM sebb wrote: > > > > Use the machine-parseable E42 error codes. That's exactly what > > > > they're for. (which-error.py and svn_error_symbolic_name() can be used > > > > to convert numbers to symbolic names.) > > > > > > Where are these error codes defined? > > > I could not find any reference to them in the documentation. > > > > If you mean where in the source code: > > > > subversion/include/svn_error_codes.h > > which is included by subversion/include/svn_error.h, which is further > > included by subversion/svnmucc/svnmucc.c. > > > > Hope that helps, > > Thanks, but not really. > > If the error codes are intended to be machine-parseable then the > programmer needs to have documentation of the values and their > meanings. > There needs to be at least a mention in the documentation that such > codes exist and where to find the values. If there is such a mention, > I could not find it. Doxygen docs of svn_error_t::apr_err. > Also, I had a look at the file and it does not show the numeric > values, I refer you again to which-error.py. > and whilst there is a text string associated with each one it > does not detail when it might be used. > Nor indeed do the strings agree with the actual messages generated by > SVN as far as I can tell. No, they don't. The strings in that file are defaults, only used when the line of code that raised an error didn't provide a more specific string. > e.g. svn list reports the following: > > svn: warning: W160013: Path '/x' not found > svn: E29: Could not list all targets because some targets don't exist Great. Run which-error.py on this and you'll find that the former code is SVN_ERR_FS_NOT_FOUND. That's basically the svn API equivalent of ENOENT, i.e., "There's no node by that name in the versioned filesystem". Therefore, you'll want to write your script to handle E160013 errors by ignoring them and continuing. The complication here is that `svn list` supports multiple target arguments, and has to handle the case that some but not all of them are invalid. It does so by reporting the errors from individual targets as W* codes rather than E* codes and adding a generic E29 error at the end. You can either parse stderr despite this complication, or use the API directly, in which case you'll sidestep this complication entirely (you'll get just one integer, rather than two). Daniel
Re: svnmucc: new commands: add and modify/update
sebb wrote on Wed, 22 Jul 2020 22:44 +0100: > The SVN put command can add a new file or update an existing one. > > As part of a batch update it may be necessary to ensure that a > particular file will be created and not updated - or vice versa. > That is currently not at all easy to do, which is a shame as svnmucc > is otherwise very useful for writing atomic updates that are not > possible with the svn client. What can svnmucc(1) do that svn(1) can't? > Would there be any support for extending svnmucc to add these operations? > Either as options to put, or as separate commands. The standard solutions for your situation are: 1. - Get HEAD's value as an integer - Check file existence/inexistence in that revision - Run 'svnmucc -r' 2. svn co --depth=empty $URL wc svn up --set-depth=infinity wc/foo ⋮ # (as posted in https://mail-archives.apache.org/mod_mbox/subversion-users/202007.mbox/%3C20200712142604.128f80eb%40tarpaulin.shahaf.local2%3E) In what ways do they fall short?
svnmucc: new commands: add and modify/update
The SVN put command can add a new file or update an existing one. As part of a batch update it may be necessary to ensure that a particular file will be created and not updated - or vice versa. That is currently not at all easy to do, which is a shame as svnmucc is otherwise very useful for writing atomic updates that are not possible with the svn client. Would there be any support for extending svnmucc to add these operations? Either as options to put, or as separate commands. Sebb.
Re: svnmucc --revision 0 no longer works when creating a file
On Wed, 22 Jul 2020 at 17:46, Nathan Hartman wrote: > > On Wed, Jul 22, 2020 at 12:10 PM sebb wrote: > > > Use the machine-parseable E42 error codes. That's exactly what > > > they're for. (which-error.py and svn_error_symbolic_name() can be used > > > to convert numbers to symbolic names.) > > > > Where are these error codes defined? > > I could not find any reference to them in the documentation. > > If you mean where in the source code: > > subversion/include/svn_error_codes.h > which is included by subversion/include/svn_error.h, which is further > included by subversion/svnmucc/svnmucc.c. > > Hope that helps, Thanks, but not really. If the error codes are intended to be machine-parseable then the programmer needs to have documentation of the values and their meanings. There needs to be at least a mention in the documentation that such codes exist and where to find the values. If there is such a mention, I could not find it. Also, I had a look at the file and it does not show the numeric values, and whilst there is a text string associated with each one it does not detail when it might be used. Nor indeed do the strings agree with the actual messages generated by SVN as far as I can tell. e.g. svn list reports the following: svn: warning: W160013: Path '/x' not found svn: E29: Could not list all targets because some targets don't exist But I could not find similar strings in the header file; e.g. the only string containing targets is: "Duplicate targets in svn:externals property" So I don't think the header file is suitable for writing software to analyse the error codes. > Nathan
Re: svnmucc --revision 0 no longer works when creating a file
On Wed, Jul 22, 2020 at 12:10 PM sebb wrote: > > Use the machine-parseable E42 error codes. That's exactly what > > they're for. (which-error.py and svn_error_symbolic_name() can be used > > to convert numbers to symbolic names.) > > Where are these error codes defined? > I could not find any reference to them in the documentation. If you mean where in the source code: subversion/include/svn_error_codes.h which is included by subversion/include/svn_error.h, which is further included by subversion/svnmucc/svnmucc.c. Hope that helps, Nathan
Re: svnmucc --revision 0 no longer works when creating a file
On Sun, 12 Jul 2020 at 18:13, Daniel Shahaf wrote:
>
> sebb wrote on Sun, 12 Jul 2020 16:55 +0100:
> > On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
> > >
> > > sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > > > When I first started using svnmucc, it used to be the case that
> > > > svnmucc 'put' --revision 0 would fail if the target file already
> > > > existed. This no longer happens.
> > > >
> > >
> > > Is the file-to-be's parent directory the root directory?
> >
> > No, it's not.
> >
> > > If that isn't the case, then the new behaviour is correct.
> >
> > Why is that?
> >
>
> Because the target of the 'put' operation didn't exist at r0, and the
> base revision is specified to be a revision in which the target of the
> operation existed. (See svn_delta_editor_t::open_root()'s docstring.)
>
> Moreover, even that syntax it did work, it should arguably fail if the
> file had been created and subsequently deleted, which isn't the same
> semantics as the algorithm you posted.
>
> > > You might wish to post the error message.
> >
> > Just tried with a local SVN repo:
> >
> > $ svnmucc -mBug --revision 0 -- put /dev/null
> > file:///var/tools/svnrep/asf/x/b.tmp
> > svnmucc: E160016: Can't commit to 'file:///var/tools/svnrep/asf/x'
> > because it is not a directory
> >
> > That message is wrong, because /x/ *is* a directory.
>
> Runnable reproduction recipe, please.
>
> I wonder if the error is reported because /x isn't a directory _at r0_,
> per the above explanation. What happens if you try to put a file into
> the root directory? If you keep the target as-is but change the value
> of the --revision argument to the revision in which ^/x was created? To
> the revision just before that?
>
> > The same error occurs regardless of whether b.tmp is present.
> >
> > > > The previous behaviour was very useful, so are there any plans to
> > > > reinstate it?
> > > >
> > >
> > > Patches welcome. (You'll have to propose a new syntax, of course.)
> >
> > --revision -1
>
> -1 actually already has a meaning (SVN_INVALID_REVNUM). More
> importantly, this approach makes it impossible to specify a base
> revision if any single operation is a "create exclusively" operation.
> Shouldn't the new syntax be per-operation, so people could combine
> "create exclusively" operations, "create or update" operations, and
> other kinds of operations in the same command line, _and_ have the
> option of specifying a base revision as well?
>
> > > > I don't think there is a straightforward way to guarantee the same
> > > > behaviour now.
> > > >
> > >
> > > Try:
> > >
> > > svn checkout --depth=empty $URL wc
> > > cd wc
> > > svn up --set-depth=infinite iota
> > > touch iota
> > > svn add iota
> > > svn commit -mm
> > > svn up --set-depth=empty iota
> > > svn cleanup# prune .svn/pristine
> >
> > Not exactly straightforward, but it does fail if the file has been
> > created meanwhile
> > However the error response still has to be analysed
> >
> > Also the script can fail in at least two places, depending on when the
> > file is created.
> >
>
> And why is that a problem?
>
> In the future, please provide all the needed information (reproduction
> recipes, error messages, the answer to "Why is it a problem?") up front.
> I don't intend to guess the missing parts and I don't have the
> brainwidth to prompt you every time.
>
> > > > The closest I could get is:
> > > >
> > > > 1) get current parent directory revision
> > > > 2) check if target file does not exist. This is not as easy as it
> > > > sounds, as the target directory may have too many files to list
> > > > efficiently, and any other file-based command may fail for a reason
> > > > other than a missing file.
> > >
> > > How is «svn info $URL/to/file@$REV» not sufficient? You can use
> > > $URL/to{,/file}@$REV if you want, too.
> >
> > Same issue: svn info only returns success if the file exists.
> > An error may mean the file did not exist or something else, so the
> > error text has to be analysed.
>
> Use the machine-parseable E42 error codes. That's exactly what
> they're for. (which-error.py and svn_error_symbolic_name() can be used
> to convert numbers to symbolic names.)
Where are these error codes defined?
I could not find any reference to them in the documentation.
> > > > 3) Put the file using the revision obtained in step 1.
> > > > AFAICT this is guaranteed not to replace an existing file.
> > > >
> > > > However it may fail to create the file if the target directory has
> > > > been updated in the meantime.
> > > >
> > > > It's only safe to repeat the attempted create if the command failed
> > > > due to an out of date revision.
> > > > So the failure reason will have to be analysed.
> > >
> > > What part of the above is a problem, and why?
> >
> > It requires analysing the error response, which is likely to be fragile.
>
> See above.
Re: svnmucc --revision 0 no longer works when creating a file
sebb wrote on Sun, 12 Jul 2020 16:55 +0100:
> On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
> >
> > sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > > When I first started using svnmucc, it used to be the case that
> > > svnmucc 'put' --revision 0 would fail if the target file already
> > > existed. This no longer happens.
> > >
> >
> > Is the file-to-be's parent directory the root directory?
>
> No, it's not.
>
> > If that isn't the case, then the new behaviour is correct.
>
> Why is that?
>
Because the target of the 'put' operation didn't exist at r0, and the
base revision is specified to be a revision in which the target of the
operation existed. (See svn_delta_editor_t::open_root()'s docstring.)
Moreover, even that syntax it did work, it should arguably fail if the
file had been created and subsequently deleted, which isn't the same
semantics as the algorithm you posted.
> > You might wish to post the error message.
>
> Just tried with a local SVN repo:
>
> $ svnmucc -mBug --revision 0 -- put /dev/null
> file:///var/tools/svnrep/asf/x/b.tmp
> svnmucc: E160016: Can't commit to 'file:///var/tools/svnrep/asf/x'
> because it is not a directory
>
> That message is wrong, because /x/ *is* a directory.
Runnable reproduction recipe, please.
I wonder if the error is reported because /x isn't a directory _at r0_,
per the above explanation. What happens if you try to put a file into
the root directory? If you keep the target as-is but change the value
of the --revision argument to the revision in which ^/x was created? To
the revision just before that?
> The same error occurs regardless of whether b.tmp is present.
>
> > > The previous behaviour was very useful, so are there any plans to
> > > reinstate it?
> > >
> >
> > Patches welcome. (You'll have to propose a new syntax, of course.)
>
> --revision -1
-1 actually already has a meaning (SVN_INVALID_REVNUM). More
importantly, this approach makes it impossible to specify a base
revision if any single operation is a "create exclusively" operation.
Shouldn't the new syntax be per-operation, so people could combine
"create exclusively" operations, "create or update" operations, and
other kinds of operations in the same command line, _and_ have the
option of specifying a base revision as well?
> > > I don't think there is a straightforward way to guarantee the same
> > > behaviour now.
> > >
> >
> > Try:
> >
> > svn checkout --depth=empty $URL wc
> > cd wc
> > svn up --set-depth=infinite iota
> > touch iota
> > svn add iota
> > svn commit -mm
> > svn up --set-depth=empty iota
> > svn cleanup# prune .svn/pristine
>
> Not exactly straightforward, but it does fail if the file has been
> created meanwhile
> However the error response still has to be analysed
>
> Also the script can fail in at least two places, depending on when the
> file is created.
>
And why is that a problem?
In the future, please provide all the needed information (reproduction
recipes, error messages, the answer to "Why is it a problem?") up front.
I don't intend to guess the missing parts and I don't have the
brainwidth to prompt you every time.
> > > The closest I could get is:
> > >
> > > 1) get current parent directory revision
> > > 2) check if target file does not exist. This is not as easy as it
> > > sounds, as the target directory may have too many files to list
> > > efficiently, and any other file-based command may fail for a reason
> > > other than a missing file.
> >
> > How is «svn info $URL/to/file@$REV» not sufficient? You can use
> > $URL/to{,/file}@$REV if you want, too.
>
> Same issue: svn info only returns success if the file exists.
> An error may mean the file did not exist or something else, so the
> error text has to be analysed.
Use the machine-parseable E42 error codes. That's exactly what
they're for. (which-error.py and svn_error_symbolic_name() can be used
to convert numbers to symbolic names.)
> > > 3) Put the file using the revision obtained in step 1.
> > > AFAICT this is guaranteed not to replace an existing file.
> > >
> > > However it may fail to create the file if the target directory has
> > > been updated in the meantime.
> > >
> > > It's only safe to repeat the attempted create if the command failed
> > > due to an out of date revision.
> > > So the failure reason will have to be analysed.
> >
> > What part of the above is a problem, and why?
>
> It requires analysing the error response, which is likely to be fragile.
See above.
Re: svnmucc --revision 0 no longer works when creating a file
On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
>
> sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > When I first started using svnmucc, it used to be the case that
> > svnmucc 'put' --revision 0 would fail if the target file already
> > existed. This no longer happens.
> >
>
> Is the file-to-be's parent directory the root directory?
No, it's not.
> If that isn't the case, then the new behaviour is correct.
Why is that?
> You might wish to post the error message.
Just tried with a local SVN repo:
$ svnmucc -mBug --revision 0 -- put /dev/null
file:///var/tools/svnrep/asf/x/b.tmp
svnmucc: E160016: Can't commit to 'file:///var/tools/svnrep/asf/x'
because it is not a directory
That message is wrong, because /x/ *is* a directory.
The same error occurs regardless of whether b.tmp is present.
> > The previous behaviour was very useful, so are there any plans to reinstate
> > it?
> >
>
> Patches welcome. (You'll have to propose a new syntax, of course.)
--revision -1
> > I don't think there is a straightforward way to guarantee the same
> > behaviour now.
> >
>
> Try:
>
> svn checkout --depth=empty $URL wc
> cd wc
> svn up --set-depth=infinite iota
> touch iota
> svn add iota
> svn commit -mm
> svn up --set-depth=empty iota
> svn cleanup# prune .svn/pristine
Not exactly straightforward, but it does fail if the file has been
created meanwhile
However the error response still has to be analysed
Also the script can fail in at least two places, depending on when the
file is created.
> > The closest I could get is:
> >
> > 1) get current parent directory revision
> > 2) check if target file does not exist. This is not as easy as it
> > sounds, as the target directory may have too many files to list
> > efficiently, and any other file-based command may fail for a reason
> > other than a missing file.
>
> How is «svn info $URL/to/file@$REV» not sufficient? You can use
> $URL/to{,/file}@$REV if you want, too.
Same issue: svn info only returns success if the file exists.
An error may mean the file did not exist or something else, so the
error text has to be analysed.
> > 3) Put the file using the revision obtained in step 1.
> > AFAICT this is guaranteed not to replace an existing file.
> >
> > However it may fail to create the file if the target directory has
> > been updated in the meantime.
> >
> > It's only safe to repeat the attempted create if the command failed
> > due to an out of date revision.
> > So the failure reason will have to be analysed.
>
> What part of the above is a problem, and why?
It requires analysing the error response, which is likely to be fragile.
Re: svnmucc --revision 0 no longer works when creating a file
sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> When I first started using svnmucc, it used to be the case that
> svnmucc 'put' --revision 0 would fail if the target file already
> existed. This no longer happens.
>
Is the file-to-be's parent directory the root directory? If that isn't
the case, then the new behaviour is correct.
You might wish to post the error message.
> The previous behaviour was very useful, so are there any plans to reinstate
> it?
>
Patches welcome. (You'll have to propose a new syntax, of course.)
> I don't think there is a straightforward way to guarantee the same
> behaviour now.
>
Try:
svn checkout --depth=empty $URL wc
cd wc
svn up --set-depth=infinite iota
touch iota
svn add iota
svn commit -mm
svn up --set-depth=empty iota
svn cleanup# prune .svn/pristine
> The closest I could get is:
>
> 1) get current parent directory revision
> 2) check if target file does not exist. This is not as easy as it
> sounds, as the target directory may have too many files to list
> efficiently, and any other file-based command may fail for a reason
> other than a missing file.
How is «svn info $URL/to/file@$REV» not sufficient? You can use
$URL/to{,/file}@$REV if you want, too.
> 3) Put the file using the revision obtained in step 1.
> AFAICT this is guaranteed not to replace an existing file.
>
> However it may fail to create the file if the target directory has
> been updated in the meantime.
>
> It's only safe to repeat the attempted create if the command failed
> due to an out of date revision.
> So the failure reason will have to be analysed.
What part of the above is a problem, and why?
svnmucc --revision 0 no longer works when creating a file
When I first started using svnmucc, it used to be the case that svnmucc 'put' --revision 0 would fail if the target file already existed. This no longer happens. The previous behaviour was very useful, so are there any plans to reinstate it? I don't think there is a straightforward way to guarantee the same behaviour now. The closest I could get is: 1) get current parent directory revision 2) check if target file does not exist. This is not as easy as it sounds, as the target directory may have too many files to list efficiently, and any other file-based command may fail for a reason other than a missing file. 3) Put the file using the revision obtained in step 1. AFAICT this is guaranteed not to replace an existing file. However it may fail to create the file if the target directory has been updated in the meantime. It's only safe to repeat the attempted create if the command failed due to an out of date revision. So the failure reason will have to be analysed.
Re: Restriction on svnmucc targets in same repository?
sebb wrote on Tue, 07 Jul 2020 12:55 +0100: > Is there any restriction on svnmucc targets which can appear in a batch > script? > > I assume that all targets must be in the same repository, but are > there any further restrictions, e.g. must they have the same initial > root directory path? > > I ask this because I am getting the following: > > svnmucc: E175013: Access to '/.../!svn/rvr/98024' forbidden > > The script is equivalent to: > > put > file.txt > top1/file.txt > > mv > top2/d1/file2.txt > top2/d2/file2.txt > > top1 and top2 are different top-level root folders in the same repository, > i.e. > svn info root/top1 gives the same UUID as svn info root/top2 There are no restrictions other than "in the same repository". However, if you edit both ^/top1/foo and ^/top2/bar in the same revision, the edit drive will be rooted on ^/, and it's possible you need 'w' access on ^/ in the authz file for that to work. (See «svnauthz accessof») And of course, check the server logs for hints.
Restriction on svnmucc targets in same repository?
Is there any restriction on svnmucc targets which can appear in a batch script? I assume that all targets must be in the same repository, but are there any further restrictions, e.g. must they have the same initial root directory path? I ask this because I am getting the following: svnmucc: E175013: Access to '/.../!svn/rvr/98024' forbidden The script is equivalent to: put file.txt top1/file.txt mv top2/d1/file2.txt top2/d2/file2.txt top1 and top2 are different top-level root folders in the same repository, i.e. svn info root/top1 gives the same UUID as svn info root/top2 Sebb
RE: svnmucc fails to build from sources
Nevermind. Seeing that /usr/local/lib was included in the compile line as "rpath", I tried moving all existing libsvn_* files from /usr/local/lib to an "old_1.11" directory (they came from the 1.11 compilation) After that, "make" just went fine. Regards, Juanga
svnmucc fails to build from sources
Hello, Build box is an Ubuntu 18.04 where only standard system updates are applied. Built svn 1.11.0 from sources with no problems, now trying to build the latest 1.12.2 is throwing the following error. [...] cd subversion/svnmucc && /bin/bash "/usr/local/src/subversion-1.12.2/libtool" --tag=CC --silent --mode=link gcc -g -O2 -pthread-rpath /usr/local/lib -o svnmucc svnmucc.lo ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la -L/usr/lib/x86_64-linux-gnu -laprutil-1 -L/usr/lib/x86_64-linux-gnu -lapr-1 ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined reference to `svn_wc__get_experimental_dir' ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined reference to `svn_wc__find_copies_of_repos_path' collect2: error: ld returned 1 exit status build-outputs.mk:1194: recipe for target 'subversion/svnmucc/svnmucc' failed make: *** [subversion/svnmucc/svnmucc] Error 1 I have lots of the following, can't recall if it's "normal". ar: `u' modifier ignored since `D' is the default (see `U') Any insight would be greatly appreciated. Thanks! Juan
Re: svnmucc and creating new files in existing directories
Sam Ruby wrote on Mon, 05 Jun 2017 14:24 -0400: > On 06/05/2017 02:10 PM, Daniel Shahaf wrote: > > Sam Ruby wrote on Mon, 05 Jun 2017 10:08 -0400: > >> When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn > >> 1.9.3), svnmucc commands started failing for me: > >> > >> $ svnmucc --revision 0 --message 'test data, please ignore' -- put - > >> https://svn.apache.org/repos/private/financials/Bills/paid/test < test > >> svnmucc: E160016: Can't commit to > >> 'https://svn.apache.org/repos/private/financials/Bills/paid' because it > >> is not a directory > >> > >> I can continue to replace svnmucc with svn checkout --depth empty; svn > >> add, svn commit sequences; but I was wondering if I'm using svnmucc > >> incorrectly? > > > > I assume it works if you leave the --revision out? The directory in > > question doesn't exist in r0, so I wouldn't expect the command to work > > as written. > > OK, that worked. Thanks! > > FWIW, I'm pretty sure that was cargo-culted from a script you had > written (the mailing list subscription tool, to be specific), and the > comment that line had was as follows: > > # add file to svn (--revision 0 means it won't overwrite an existing file) > I can't find that line in my working copy or in my commits list archives. > Which leads to a question: what will svnmucc do if the file already exists? Overwrite it. (Hopefully, someone will notice that the commit mail says 'M' rather than 'A' in the changed-paths list.) The way it's supposed to work is, to modify a file, you get its contents as of a known revision number, modify it, and then pass the revision number back via the --revision argument; there is an example of this in trunk/tlpreq/scripts/website in the helper function _append_to_URL(). Now, the same holds for creating a file: if you know that the file doesn't exist in r42, then passing --revision=42 will cause the commit to error out if it would modify (as opposed to create) the file. (That's exactly analogous to out of date working copies.) This is what you can have whimsy use. As to --revision=0, apparently 1.8 interprets that as "Create a new file", while 1.9 just errors out since the containing directory didn't exist at r0. I'm not sure how to classify this delta: whether it's a intentional change / bugfix / regression. The --revision=0 usage was probably inspired by the 'svn up -r0' syntax, however, that syntax works identically in 1.8/1.9/1.10. Daniel
Re: svnmucc and creating new files in existing directories
On 06/05/2017 02:10 PM, Daniel Shahaf wrote: Sam Ruby wrote on Mon, 05 Jun 2017 10:08 -0400: When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn 1.9.3), svnmucc commands started failing for me: $ svnmucc --revision 0 --message 'test data, please ignore' -- put - https://svn.apache.org/repos/private/financials/Bills/paid/test < test svnmucc: E160016: Can't commit to 'https://svn.apache.org/repos/private/financials/Bills/paid' because it is not a directory I can continue to replace svnmucc with svn checkout --depth empty; svn add, svn commit sequences; but I was wondering if I'm using svnmucc incorrectly? I assume it works if you leave the --revision out? The directory in question doesn't exist in r0, so I wouldn't expect the command to work as written. OK, that worked. Thanks! FWIW, I'm pretty sure that was cargo-culted from a script you had written (the mailing list subscription tool, to be specific), and the comment that line had was as follows: # add file to svn (--revision 0 means it won't overwrite an existing file) Which leads to a question: what will svnmucc do if the file already exists? - Sam Ruby
Re: svnmucc and creating new files in existing directories
Sam Ruby wrote on Mon, 05 Jun 2017 10:08 -0400: > When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn > 1.9.3), svnmucc commands started failing for me: > > $ svnmucc --revision 0 --message 'test data, please ignore' -- put - > https://svn.apache.org/repos/private/financials/Bills/paid/test < test > svnmucc: E160016: Can't commit to > 'https://svn.apache.org/repos/private/financials/Bills/paid' because it > is not a directory > > I can continue to replace svnmucc with svn checkout --depth empty; svn > add, svn commit sequences; but I was wondering if I'm using svnmucc > incorrectly? I assume it works if you leave the --revision out? The directory in question doesn't exist in r0, so I wouldn't expect the command to work as written.
svnmucc and creating new files in existing directories
When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn 1.9.3), svnmucc commands started failing for me: $ svnmucc --revision 0 --message 'test data, please ignore' -- put - https://svn.apache.org/repos/private/financials/Bills/paid/test < test svnmucc: E160016: Can't commit to 'https://svn.apache.org/repos/private/financials/Bills/paid' because it is not a directory I can continue to replace svnmucc with svn checkout --depth empty; svn add, svn commit sequences; but I was wondering if I'm using svnmucc incorrectly? - Sam Ruby
Re: svnmucc and line endings
Thank you very much for the speedy change! On Fri, May 2, 2014 at 10:54 PM, Ben Reser b...@reser.org wrote: On 5/2/14, 3:24 PM, Dan Ellis wrote: svnmucc currently only supports linefeed (LF, \n) line endings and complains about window's style carriage return, linefeed (CRLFs, \r\n) with: Error: svnmucc: E125005: Cannot accept non-LF line endings in 'svn:log' property This is inconsistent with the svn command line that allows both but requires consistency. Is there any consideration of supporting both styles? Not supporting \r\n causes some scripting pain to clean up the file to the single format. Done on trunk in r1592148 and r1592150. For what it's worth it is also inconsistent with svnmucc since when SVN_EDITOR is called to retrieve the log message it handles line ending normalization. Thanks for the request.
svnmucc and line endings
Hi, svnmucc currently only supports linefeed (LF, \n) line endings and complains about window's style carriage return, linefeed (CRLFs, \r\n) with: Error: svnmucc: E125005: Cannot accept non-LF line endings in 'svn:log' property This is inconsistent with the svn command line that allows both but requires consistency. Is there any consideration of supporting both styles? Not supporting \r\n causes some scripting pain to clean up the file to the single format. Thanks, Dan
Re: svnmucc and line endings
On 5/2/14, 3:24 PM, Dan Ellis wrote: svnmucc currently only supports linefeed (LF, \n) line endings and complains about window's style carriage return, linefeed (CRLFs, \r\n) with: Error: svnmucc: E125005: Cannot accept non-LF line endings in 'svn:log' property This is inconsistent with the svn command line that allows both but requires consistency. Is there any consideration of supporting both styles? Not supporting \r\n causes some scripting pain to clean up the file to the single format. Done on trunk in r1592148 and r1592150. For what it's worth it is also inconsistent with svnmucc since when SVN_EDITOR is called to retrieve the log message it handles line ending normalization. Thanks for the request.
Re: svnmucc
Brother, unweaving the quotes is its own problem. You see, most filesystems allow single quotes and double quotes in the filenames themselves. Hilarity will ensue. On Sun, Nov 17, 2013 at 4:19 AM, Vladislav Javadov vapaam...@yandex.ru wrote: BZ The reason to support this syntax with command and arg on separate lines BZ is to support files with whitespaces in the names But what about quotes? Most OSes and programs accept quoted file names containing spaces. Single-line commands are more readable, IMHO. -- WBR, Vladislav Javadov
RE: svnmucc
-Original Message- From: Nico Kadel-Garcia [mailto:nka...@gmail.com] Sent: Monday, November 18, 2013 7:12 AM To: Vladislav Javadov Cc: Blair Zajac; Andreas Mohr; Geoff Rowell; users@subversion.apache.org Subject: Re: svnmucc Brother, unweaving the quotes is its own problem. You see, most filesystems allow single quotes and double quotes in the filenames themselves. Hilarity will ensue. On Sun, Nov 17, 2013 at 4:19 AM, Vladislav Javadov vapaam...@yandex.ru wrote: BZ The reason to support this syntax with command and arg on separate BZ lines is to support files with whitespaces in the names But what about quotes? Most OSes and programs accept quoted file names containing spaces. Single-line commands are more readable, IMHO. -- WBR, Vladislav Javadov And this is why I switched from bash to xash (aka xml bash). All my commands are now entered in xml format. Finally, no more -print0 and nested/escaped quotes nonsense! Example: cp -p foo bar Becomes commandargcp/argarg-p/argargfoo/argargbar/arg/command And multi-line commands and scripts go from: # Contrived example find . -type f -print0 | while read -d $'\0' i do sed 's/e/E/g' $i done | tee foo.txt 21 to: commands command argfind/arg arg./arg arg-type/arg argf/arg /command pipe/ command argwhile/arg argread/arg argi/arg /command command argdo/arg /command command argsed/arg arg's/e/E/g'/arg arg$i/arg /command command argdone/arg /command pipe/ tee stdout_format=human_ascii filefoo.txt/file /tee redirects redirectfile_no from=2 to=1//redirect /redirects /commands Simple and inherently accurate, natch?
Re: UNS: Re: svnmucc
On Mon, 18 Nov 2013 07:11:40 +, Nico Kadel-Garcia wrote: Brother, unweaving the quotes is its own problem. You see, most filesystems allow single quotes and double quotes in the filenames themselves. Hilarity will ensue. Quoting is a solved problem, including quoting quotes. Using newlines a command argument separator because there may be spaces in files names is a regression from accepted CLI design, and doesn't even solve the problem of newlines in file name which filesystems also allow. Besides, hilarity also ensues there when a file happens to be named 'rm'. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: UNS: Re: svnmucc
On Nov 18, 2013, at 7:33 AM, Andreas Krey a.k...@gmx.de wrote: On Mon, 18 Nov 2013 07:11:40 +, Nico Kadel-Garcia wrote: Brother, unweaving the quotes is its own problem. You see, most filesystems allow single quotes and double quotes in the filenames themselves. Hilarity will ensue. Quoting is a solved problem, including quoting quotes. Using newlines a command argument separator because there may be spaces in files names is a regression from accepted CLI design, and doesn't even solve the problem of newlines in file name which filesystems also allow. Besides, hilarity also ensues there when a file happens to be named 'rm’. svnmucc handles arbitrary long command line arguments with spaces if they are quoted. This is in regards to the -X command line option. Blair
Re: UNS: Re: svnmucc
Quoting is a solved problem, including quoting quotes. Bwa-ha-ha-ha!. Hee. Giggle, Snort. Oh, dear lord, that one deserved a coffee and cats warning. The handling of syntactically significant characters, such as quotes, slashes, single quotes, and spaces is a very common cross-platform problem and multiple tool problem. There are individual tools that do it well. Many, many casually written access control, hook-scripts, and and build scripts do not. And with so many interpreters having different syntax for quote handling, it can actually be impossible for one script to hand off the right number of levels of quoting to another tool several layers deeper. On Mon, Nov 18, 2013 at 10:33 AM, Andreas Krey a.k...@gmx.de wrote: On Mon, 18 Nov 2013 07:11:40 +, Nico Kadel-Garcia wrote: Brother, unweaving the quotes is its own problem. You see, most filesystems allow single quotes and double quotes in the filenames themselves. Hilarity will ensue. Quoting is a solved problem, including quoting quotes. Using newlines a command argument separator because there may be spaces in files names is a regression from accepted CLI design, and doesn't even solve the problem of newlines in file name which filesystems also allow. Besides, hilarity also ensues there when a file happens to be named 'rm'. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: svnmucc
BZ The reason to support this syntax with command and arg on separate lines BZ is to support files with whitespaces in the names But what about quotes? Most OSes and programs accept quoted file names containing spaces. Single-line commands are more readable, IMHO. -- WBR, Vladislav Javadov
Re: svnmucc
On Nov 16, 2013, at 2:10 AM, Vladislav Javadov vapaam...@yandex.ru wrote: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags Each command argument must be on a separate line: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags - Geoff
Re: svnmucc
On Sat, Nov 16, 2013 at 04:29:13AM -0500, Geoff Rowell wrote: On Nov 16, 2013, at 2:10 AM, Vladislav Javadov vapaam...@yandex.ru wrote: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags Each command argument must be on a separate line: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags So, does that mean that svnmucc has single-arg support only? Cause given this example, on the syntax side there's nothing that would indicate that a new command is following, rather than further options to the existing command... (unless rm is one of the commands which are specially recognized as a known-supported command) Sorry for my critique (and thank you for your help!) - just sayin'... Andreas Mohr
Re: svnmucc
On 11/16/2013 03:06 AM, Andreas Mohr wrote: On Sat, Nov 16, 2013 at 04:29:13AM -0500, Geoff Rowell wrote: On Nov 16, 2013, at 2:10 AM, Vladislav Javadov vapaam...@yandex.ru wrote: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags Each command argument must be on a separate line: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags So, does that mean that svnmucc has single-arg support only? Cause given this example, on the syntax side there's nothing that would indicate that a new command is following, rather than further options to the existing command... (unless rm is one of the commands which are specially recognized as a known-supported command) Sorry for my critique (and thank you for your help!) - just sayin'... Not having looked at the source code, it probably just reads from the file until it reaches the end. The reason to support this syntax with command and arg on separate lines is to support files with whitespaces in the names, which wouldn't be possible wit the syntax of command and arg on a single line. Blair
Re: svnmucc
On 11/16/13 8:38 AM, Blair Zajac wrote: The reason to support this syntax with command and arg on separate lines is to support files with whitespaces in the names, which wouldn't be possible wit the syntax of command and arg on a single line. Yet another thing to add to the list of code that assumes that filenames don't have newlines in them.
svnmucc
Hi, My svnmucc 1.8.4 can't work with commands from a file, like these (saved as 'normalize.mucc'): rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags I try execute them via svnmucc: svnmucc -U file:///X:/SVN/Kolibri.com -X normalize.mucc -m Normalization It causes me an error: svnmucc: E24: 'rm programs/develop/fasm/tags' is not an action I looked into the sources and found this error like svnmucc treats the entire string 'rm programs/develop/fasm/tags' as single command. Is it real? Is it common issue, not just for Windows? -- WBR, Vladislav Javadov
svnmucc assertion failure
Hi,
I've hit the following assertion in svnmucc:
svnmucc: subversion/libsvn_subr/dirent_uri.c:1373:
svn_uri_get_longest_ancestor: Assertion `svn_uri_is_canonical(uri1, ((void
*)0))' failed.
Aborted (core dumped)
The assertion was triggered when svnmucc was supplied with a script file that
had inconsistent URL specifications (it was cut-and-pasted from two different
scripts, one of which referred to SVN server by IP and the other by its domain
name). It can be easily reproduced with the following script, for example (no
repository setup is needed, as this assertion is triggered even before svnmucc
contacts the repository):
mkdir
svn://localhost/svn/branches/try
cp
1234
svn://127.0.0.1/svn/trunk/foo
svn://localhost/svn/branches/try/foo
I am not sure if it is a valid use case, but at the very least, the error
message should probably be me a bit more user-friendly than an assertion.
Patch erring out gracefully attached.
Regards,
Alexey.
Index: subversion/svnmucc/svnmucc.c
===
--- subversion/svnmucc/svnmucc.c (revision 1508998)
+++ subversion/svnmucc/svnmucc.c (working copy)
@@ -1433,7 +1433,14 @@
if (! anchor)
anchor = url;
else
-anchor = svn_uri_get_longest_ancestor(anchor, url, pool);
+{
+ anchor = svn_uri_get_longest_ancestor(anchor, url, pool);
+ if (!anchor[0])
+handle_error(svn_error_createf(SVN_ERR_INCORRECT_PARAMS, NULL,
+ URLs in the action list do not
+ share a common ancestor\n),
+ pool);
+}
if ((++i == action_args-nelts) (j + 1 num_url_args))
insufficient(pool);
Re: svnmucc installation bug in Subversion 1.8.0
On Fri, Jun 21, 2013 at 4:45 AM, Philip Martin philip.mar...@wandisco.com wrote: Nico Kadel-Garcia nka...@gmail.com writes: # Compatibility symlink. # This runs after the target of the same name in build-outputs.mk. INSTALL_EXTRA_TOOLS=\ $(MKDIR) $(DESTDIR)$(bindir); \ test -n $$SVN_SVNMUCC_IS_SVNSYITF \ ln -sf svnmucc$(EXEEXT) $(DESTDIR)$(bindir)/svnsyitf$(EXEEXT); \ if test $(DESTDIR)$(bindir) != $(DESTDIR)$(toolsdir); then \ ln -sf $(DESTDIR)$(bindir)/svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ fi Unfortunately, when building RPM's DESTDIR is the location of the RPM BUILDROOT location, not the atual deployment location. So it needs to be: ln -sf $(bindir)/svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ So can I safely assume that I just need to patch that for RPM building? That should work. I fixed Makefile.in in r1495329. Does your binary package include /usr/bin/svn-tools? Yes, it does. Thanks. The original but of shell scripting is a classic attempt to have a Makefile outsimart a standard build procedure, and it's not surprising when these break down in actual package building environments. In fact, I'm not sure that it *should* be altered for normal, non-RPM building deployment.
Re: svnmucc installation bug in Subversion 1.8.0
Nico Kadel-Garcia nka...@gmail.com writes: # Compatibility symlink. # This runs after the target of the same name in build-outputs.mk. INSTALL_EXTRA_TOOLS=\ $(MKDIR) $(DESTDIR)$(bindir); \ test -n $$SVN_SVNMUCC_IS_SVNSYITF \ ln -sf svnmucc$(EXEEXT) $(DESTDIR)$(bindir)/svnsyitf$(EXEEXT); \ if test $(DESTDIR)$(bindir) != $(DESTDIR)$(toolsdir); then \ ln -sf $(DESTDIR)$(bindir)/svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ fi Unfortunately, when building RPM's DESTDIR is the location of the RPM BUILDROOT location, not the atual deployment location. So it needs to be: ln -sf $(bindir)/svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ So can I safely assume that I just need to patch that for RPM building? That should work. I fixed Makefile.in in r1495329. Does your binary package include /usr/bin/svn-tools? -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
svnmucc installation bug in Subversion 1.8.0
I'm trying to build up a subversion-1.8.0 SRPM toolkit, and have noticed a little svnucc deployment bug. Specifically, the Makefile winds up saying this: # Compatibility symlink. # This runs after the target of the same name in build-outputs.mk. INSTALL_EXTRA_TOOLS=\ $(MKDIR) $(DESTDIR)$(bindir); \ test -n $$SVN_SVNMUCC_IS_SVNSYITF \ ln -sf svnmucc$(EXEEXT) $(DESTDIR)$(bindir)/svnsyitf$(EXEEXT); \ if test $(DESTDIR)$(bindir) != $(DESTDIR)$(toolsdir); then \ ln -sf $(DESTDIR)$(bindir)/svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ fi Unfortunately, when building RPM's DESTDIR is the location of the RPM BUILDROOT location, not the atual deployment location. So it needs to be: ln -sf $(bindir)/svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ So can I safely assume that I just need to patch that for RPM building?
Recursive setting of versioned properties using URL using propedit or svnmucc
Hi, I'm trying to write a skript to set versioned properties after been triggered by a hook but I seem to get stuck finding a solution and hope someone here is able to help me or point out if it's not possible. I'd like to set a property for every file in a certain directory(recursivly) using an url. Something like svn propedit -R PROPNAME PROPVAL URL or svnmucc propset PROPNAME PROPVAL -R URL My problem is that propedit doesn't support recursivly setting of properties and svnmucc gives an error( 'file already exists') when been used on a file. I'd also be glad if someone had a link to a kind of documentation for svnmucc which I haven't been able to find till now because I would like to avoid raising the revision number for each file/dir. Kind regard Bettual
Re: Recursive setting of versioned properties using URL using propedit or svnmucc
Bettual Richter wrote: I'm trying to write a skript to set versioned properties after been triggered by a hook but I seem to get stuck finding a solution and hope someone here is able to help me or point out if it's not possible. I'd like to set a property for every file in a certain directory(recursivly) using an url. Something like svn propedit -R PROPNAME PROPVAL URL I think you meant propset but anyhow svn prop* for versioned properties only work in on a working copy. the remote version only works for revision properties or svnmucc propset PROPNAME PROPVAL -R URL svnmucc has no -R option. My problem is that propedit doesn't support recursivly setting of properties and svnmucc gives an error( 'file already exists') when been used on a file. I'd also be glad if someone had a link to a kind of documentation for svnmucc which I haven't been able to find till now because I would like to avoid raising the revision number for each file/dir. you either need to checkout to a temporary working copy apply the properties and commit, or generate a file containing one 'propset PROPNAME VAL URL' command per line for each file/folder you want to modify. Then call svnmucc with '--extra-args FILENAME' -- Lorenz
Re: Recursive setting of versioned properties using URL using propedit or svnmucc
Bettual Richter wrote: I'm trying to write a skript to set versioned properties after been triggered by a hook but I seem to get stuck finding a solution and hope someone here is able to help me or point out if it's not possible. I'd like to set a property for every file in a certain directory(recursivly) using an url. Something like svn propedit -R PROPNAME PROPVAL URL I think you meant propset but anyhow svn prop* for versioned properties only work in on a working copy. Sry, but that's not right. svn propedit NAME VAL URL works without a working copy. I meant propedit and have tested it extensively because it allows you to set new properties(also versioned ones) see, http://subversion.tigris.org/issues/show_bug.cgi?id=2238 comment from Noritada Kobayashi Thu Feb 1 03:55:02 -0700 2007 It's the only hint I found to figure this out Anyway thx for your idea but it doesn't really work the way I need it. I tested it using the svnmucc --extra-arg FILE with following results : 1. FILE containing one operation per line e.g. 'propset NAME VAL URL' gives 'propset NAME VAL URL' is not an action 2. FILE containing each arg in a seperate line e.g. 'propset \n NAME \n VAL \n URL' gives a correct reply and sets the right property 3. FILE containing serveral versions of 2. e.g. 'propset \n NAME \n VAL \n URL \npropset \n NAME \n VAL \n URL' gives the same error as 1. Assuming propedit works on URLs(it does) I'm trying to do something like svn propedit NAME1 VAL1 URL1 svn propedit NAME2 VAL2 URL2 svn propedit NAME3 VAL3 URL3 at once. Most suitable with only one revision change. Any further ideas would make me happy :) thanks Bettual
Re: Recursive setting of versioned properties using URL using propedit or svnmucc
On Apr 21, 2010, at 09:27, Bettual Richter wrote: On Apr 21, 2010, at 07:19, Lorenz wrote: Bettual Richter wrote: I'd like to set a property for every file in a certain directory(recursivly) using an url. Something like svn propedit -R PROPNAME PROPVAL URL I think you meant propset but anyhow svn prop* for versioned properties only work in on a working copy. Sry, but that's not right. svn propedit NAME VAL URL works without a working copy. I meant propedit and have tested it extensively because it allows you to set new properties(also versioned ones) see, http://subversion.tigris.org/issues/show_bug.cgi?id=2238 comment from Noritada Kobayashi Thu Feb 1 03:55:02 -0700 2007 It's the only hint I found to figure this out True, svn propedit can be used on URLs now. But svn propedit NAME VAL URL is not right. propedit does not take a VAL argument on the command line; rather, it opens an editor and you type the value there. Also, svn propedit is for editing a single property of a single file or directory. Since you want to edit properties of multiple files, svn propedit is not going to work. Anyway thx for your idea but it doesn't really work the way I need it. I tested it using the svnmucc --extra-arg FILE with following results : 1. FILE containing one operation per line e.g. 'propset NAME VAL URL' gives 'propset NAME VAL URL' is not an action 2. FILE containing each arg in a seperate line e.g. 'propset \n NAME \n VAL \n URL' gives a correct reply and sets the right property Yes, according to svnmucc --help, its --extra-args option requires one argument per line in the file. 3. FILE containing serveral versions of 2. e.g. 'propset \n NAME \n VAL \n URL \npropset \n NAME \n VAL \n URL' gives the same error as 1. Are you sure? I was able to get svnmucc to do two operations by just listing them one after another in the extra args file: cp 1 file:///tmp/repo/foo file:///tmp/repo/foo2 cp 1 file:///tmp/repo/foo file:///tmp/repo/foo3 Though I am using the cp command here, and not propset; the propset command is not working for me for some reason; I'm getting the same error you reported earlier: svnmucc: File already exists: filesystem '/tmp/repo/db', transaction '2-3', path '/foo' Assuming propedit works on URLs(it does) I'm trying to do something like svn propedit NAME1 VAL1 URL1 svn propedit NAME2 VAL2 URL2 svn propedit NAME3 VAL3 URL3 at once. Most suitable with only one revision change. propedit does work on URLs, but only on one URL at a time. Doing multiple actions in a single revision change without having a working copy is only possible using the svnmucc tool; that's the purpose of the svnmucc tool in fact. The other option already mentioned is to do your changes in a working copy. Those are the two options I'm aware of for accomplishing what you want. Well, the third option would be to write a program to do this using the Subversion language bindings. But that's a lot of work, and probably unnecessary since the other two methods suggested above should work and are easier.
Cannot svnmucc handle put and mv in one transaction?
### I set up a repository like this (this is the contents of the extra args file specified by svnmucc -X): mkdir file:///C:/Temp/repo/trunk mkdir file:///C:/Temp/repo/trunk/test put file.v1.txt file:///C:/Temp/repo/trunk/test/file.txt mkdir file:///C:/Temp/repo/tags mkdir file:///C:/Temp/repo/tags/test ### Now I want to update the file and make a tag (this is given to a second svnmucc -X command): put file.v2.txt file:///C:/Temp/repo/trunk/test/file.txt mv file:///C:/Temp/repo/trunk/test file:///C:/Temp/repo/tags/test/1.0 ### svn cat file:///C:/Temp/repo/tags/test/1.0/file.txt gives the contents of file.v1.txt Is there a way to update a file and move its parent directory in the same svnmucc command? Shouldn't svnmucc give an error instead of silently ignoring my update? I'm using svn 1.6.6. /$
