Re: Consistency Amongst the Command Line Client Handling Nonexistent Paths

[Julian Foad <ju...@btopenworld.com>]

Thanks, Jeremy, for posting the results of this survey of svn commands'
behaviour in one class of abnormal use cases. This is just a starting
point for anybody who may want to plan to make the behaviour a bit more
consistent. They will also want to survey the results of other abnormal
use cases, such as when the target item exists on disk but is
unversioned, and show the exit code and whether svn continues as well as
the message it gives. Then they could look for groups of commands that
share a similar characteristic, and for consistency within those
groups... and, finding no such consistency, could propose some. Heh.

Though I prompted you to send this for the record, I wouldn't expect
much reaction to it unless somebody is actively interested in pursuing
it.

- Julian


On Wed, 2008-08-27 at 14:24 -0600, Jeremy Whitlock wrote:
> Hi All,
>     While working on issue 2269:
> 
> http://subversion.tigris.org/issues/show_bug.cgi?id=2269
> 
> I have found some interesting information about the consistency of
> handling non-existent files.  Issue 2269 started as a way to add some
> consistency to svn rm|st|up when being ran against files that do not
> exist in the working copy but may or may not exist in the repository.
> After checking most of the other svn commands against nonexistent
> paths, I have come up with the following list of commands with their
> output:
> 
> svn blame CHANGES
> svn: 'CHANGES' is not under version control
> svn cat CHANGES
> svn: warning: 'CHANGES' is not under version control
> svn copy CHANGES CHANGES2
> svn: Path 'CHANGES' does not exist
> svn del CHANGES
> svn: 'CHANGES' does not exist
> svn diff CHANGES
> svn: 'CHANGES' is not under version control
> svn info CHANGES
> svn: 'CHANGES' is not under version control
> svn lock CHANGES -m "Testing."
> svn: '/private/tmp/test/trunk/CHANGES' is not under version control
> svn log CHANGES
> svn: 'CHANGES' is not under version control
> svn proplist CHANGES
> svn: warning: 'CHANGES' is not under version control
> svn st CHANGES
> svn st -u CHANGES
>        *            CHANGES
> Status against revision:     36
> svn unlock CHANGES
> svn: '/private/tmp/test/trunk/CHANGES' is not under version control
> svn up CHANGES
> A    CHANGES
> Updated to revision 36.
> 
> As you can see, there are two only tested scenarios that will check
> against the repository equivalent path if the path does not exist in
> the local working copy: "svn st -u" and "svn up".  The rest give some
> sort of error/warning about the file not existing or not being under
> version control.  "svn st" doesn't even output anything.  (That
> appears to be one of the main reasons behind issue 2269.)  The reason
> for this email is to share my findings with the rest of the team.  How
> should a command handle this scenario, since there appear to be a few
> differing ways displayed above?  Should the command issue an error and
> stop, issue a warning and attempt to keep going about its business or
> should the repository then be contacted to attempt to get the
> information from the repository?  I see examples of each happening
> above and the answer to this question could impact how issue 2269 is
> addressed.  (We have agreed on an implementation for issue 2269 but
> with the issue not being fixed, I'm up to suggestions.)
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org