Consistency Amongst the Command Line Client Handling Nonexistent Paths

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

-- 
Take care,
Jeremy Whitlock
http://www.thoughtspark.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org