You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Matthew Sanderson <ma...@formtrap.com> on 2006/03/20 07:13:27 UTC

Exit status of 'svn' program is all screwy

Hi,

I would like the svn command-line program to exit with a non-zero status
when it failed to do what I told it to do, like other UNIX and even DOS
programs. At the moment SVN 1.3.0 does this in some error conditions but
not in others, and I can't make sense out of the behaviour I see - it
looks incorrect to me. I can't find anything at all in The Book about the
exit status of the command-line 'svn' client program.

For example, is it the intended behaviour that 'svn update' exit with
status 0 when I told it to update the working copy, and a conflict
occurred as a result of that update? I would like this case to return an
error so we can detect this in build scripts, instead of doing ugly things
like 'svn update | grep '^C'. Or maybe make this user-selectable using
'--strict' or something if the silent-fail behaviour is also desired in
different circumstances.

Similarly, 'svn update foo' where foo does not exist exits with status
0. In what possible sense has the requested operation (to update something
that does not exist) been successful? Surely this is a bug.

Similarly, attempting a 'resolved' operation on a WC to which I don't have
write access results in both an error message *and* a successful exit
status, which is a bit schizophrenic of Subversion.

But contrarily, attempting to checkout from a server name or a repository
location which does not exist does cause svn to exit with non-zero status.

Some experiments to show not tell what I mean:

1. Tell SVN to update something that does exist, but cannot be updated
because it is not a working copy.

# svn update /tmp ; echo $?
Skipped '/tmp'
0
Ok, /tmp is not a WC but that is not an error. I can live with this,
especially as I can see how others could need this behavour. But giving me
a switch with which to request an error status in this case would be nice.

2. Tell SVN to update something which does not exist.

# svn update no.such.file ; echo $?
Skipped 'no.such.file'
0
Wtf? It didn't skip that file - there was no such file present in order to
be skipped. What is the sound of one hand clapping?

3. Tell SVN to check out from a nonexistent host.

# svn co https://no.such.host/ ; echo $?
svn: PROPFIND request failed on '/'
svn: PROPFIND of '/': Could not resolve hostname `no.such.host': Host
not found (https://no.such.host)
1
# Perfect.

4. Tell SVN to check out from a nonexistent path on a present host.

# svn co https://svn/repos/no.such.path ; echo $?
svn: URL 'https://svn/repos/no.such.path' doesn't exist
1
# Perfect.

5. Tell SVN to mark a working copy as resolved which is not in conflict
and which is not writable by my current user (because I chowned it to
another user specifically to break SVN).

# svn resolved . ; echo $?
svn: warning: Can't open file '.svn/lock': Permission denied
0
# This case at least is clearly incorrect.

Cheers,

--matt

Matthew Sanderson
Senior Programmer (UNIX)
TCG Information Systems Pty Ltd
Sydney, Australia
matthew@formtrap.com
http://www.formtrap.com/
+61 (02) 8303 2407

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

Re: Exit status of 'svn' program is all screwy

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 20, 2006, at 08:13, Matthew Sanderson wrote:

> I would like the svn command-line program to exit with a non-zero  
> status
> when it failed to do what I told it to do, like other UNIX and even  
> DOS
> programs. At the moment SVN 1.3.0 does this in some error  
> conditions but
> not in others, and I can't make sense out of the behaviour I see - it
> looks incorrect to me. [snip]

All I can say is I agree with everything you wrote! I feel it would  
certainly make sense to have meaningful exit stati for all svn  
commands. This probably goes along with the ever-continuing quest to  
have more-meaningful error messages.



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