On Thu, 2008-08-07 at 13:08 +0100, Ed Avis wrote:
> At the moment, 'svn propget' will die if any of the files mentioned is not under version control. For example, in an existing working copy:
>
> % mkdir a
> % cd a
> % touch a b c
> % svn add a
> % svn propget foo a b c
> svn: 'b' is not under version control
>
> This strict behaviour is great for operations like 'svn commit' or 'svn update' that may modify data somewhere. But it might be a little too pedantic for 'svn propget', which just prints some information. I suggest that svn propget, when given a filename which is not under version control, warn about it but continue to the next file. So in this example the output would be
>
> % svn propget foo a b c
> svn: 'b' is not under version control
> svn: 'c' is not under version control
Yes, I think I agree that would be better behaviour for commands that
just gather information.
> The exit status of the command should still be nonzero to indicate that something went wrong.
That's not what we do: the exit status of Subversion commands is zero
unless an error occurred, and a warning is not counted as an error.
> Do you think this feature request is reasonable? The same would apply to 'svn proplist', 'svn status' and other harmless operations.
Making svn commands behave consistently and usefully is fine. Changing
the behaviour of one command before checking consistency with the other
commands and having a plan to work to would not be fine.
Comparing other commands (I tried most of the info-gathering ones and
some that make changes):
Intolerant, only accept a single target:
[[[
$ svn blame NONEXISTENT; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn export NONEXISTENT dest-dir; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn log NONEXISTENT; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn mergeinfo $SVN_REPOS/trunk NONEXISTENT; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn switch $SVN_REPOS/trunk NONEXISTENT; echo $?
svn: 'NONEXISTENT' does not appear to be a working copy path
1
]]]
Intolerant:
[[[
$ svn diff NONEXISTENT remake.log COMMITTERS; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn info NONEXISTENT remake.log COMMITTERS; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn list NONEXISTENT remake.log COMMITTERS; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn lock NONEXISTENT remake.log COMMITTERS; echo $?
svn: '/home/julianfoad/src/subversion-trunk2/NONEXISTENT' is not under
version control
1
$ svn propedit p1 NONEXISTENT remake.log COMMITTERS; echo $?
svn: 'NONEXISTENT' is not under version control
1
$ svn propget p1 NONEXISTENT remake.log COMMITTERS; echo $?
svn: 'NONEXISTENT' is not under version control
1
]]]
Tolerant:
[[[
$ svn cat NONEXISTENT remake.log COMMITTERS; echo $?
svn: warning: 'NONEXISTENT' is not under version control
svn: warning: 'remake.log' is not under version control
The following people have commit access to the Subversion sources.
[...]
0
$ svn propdel p1 NONEXISTENT remake.log COMMITTERS; echo $?
svn: warning: 'NONEXISTENT' is not under version control
svn: warning: 'remake.log' is not under version control
property 'p1' deleted from 'COMMITTERS'.
0
$ svn proplist NONEXISTENT remake.log COMMITTERS; echo $?
svn: warning: 'NONEXISTENT' is not under version control
svn: warning: 'remake.log' is not under version control
Properties on 'COMMITTERS':
svn:mime-type
svn:eol-style
0
$ svn propset p1 v1 NONEXISTENT remake.log COMMITTERS; echo $?
svn: warning: 'NONEXISTENT' is not under version control
svn: warning: 'remake.log' is not under version control
property 'p1' set on 'COMMITTERS'
0
$ svn resolve --accept=mine-full NONEXISTENT remake.log COMMITTERS; echo
$?
svn: warning: 'NONEXISTENT' is not under version control
svn: warning: 'remake.log' is not under version control
0
$ svn revert NONEXISTENT remake.log COMMITTERS; echo $?
Skipped 'NONEXISTENT'
Skipped 'remake.log'
Reverted 'COMMITTERS'
0
$ svn status -v NONEXISTENT remake.log COMMITTERS; echo $?
? remake.log
32391 32371 danielsh COMMITTERS
0
$ svn update NONEXISTENT remake.log COMMITTERS; echo $?
At revision 32394.
At revision 32394.
At revision 32394.
0
]]]
Broken (stops even though it's only issued a warning):
[[[
$ svn changelist mylist NONEXISTENT remake.log COMMITTERS; echo $?
svn: warning: 'NONEXISTENT' is not under version control
0
]]]
Observations:
* Some inconsistency!
* "svn lock" prints the absolute path in the error message, while
others print the relative path. (Not a big deal if it's only an error
message that's affected.)
* I'm not sure whether it's reasonable for commands that only take a
single target, and/or commands only given a single target, to behave
differently (error) from commands given multiple targets (which warn).
One guiding principle is that "svn command A; svn command B" should be
similar to "svn command A B".
* "svn changelist" is broken in this regard.
* Some commands print "Skipped" without giving a reason, where the
message "svn: warning: FILENAME is not under version control" that the
other commands give would surely be better.
* I haven't got a clear distinction between groups of commands,
especially "info-gathering" versus "change-making". E.g. is "export" a
change-making command or not?
* The problem is that we haven't written down how we want the
command-line client to behave.
Would you be interested in fleshing out and summarising the
investigation, proposing rules for which commands should behave in what
way, and/or helping to code some any of the changes and fixes that we
need? Any help you can lend would be appreciated.
- Julian
---------------------------------------------------------------------
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-08 14:31:25 CEST