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?
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?
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
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.
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.
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.
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
