"Jeremy Whitlock" <jcscoobyrs_at_gmail.com> writes:
> 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.)
Well, it would depend on the command, I think... ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-27 23:07:28 CEST