Hi,
I subscribed to dev@ just this morning, so please forgive me if I do
the wrong thing :-)
The exit status of the command-line 'svn' client is broken in some cases
in 1.3.0 - see for example issue #2414 and my recent post to users@
archived at:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=46701 .
It's itching me because I want to check svn's exit status from shell
scripts. So I am preparing to scratch this itch. Is anyone else working on
this, or planning to do so soon? Am I duplicating effort?
I'm still getting my head around svn_error_t, svn_error_clear etc and the
associated error propogation semantics - it's a good idea but it's a new
approach to me in C. I'll post patches for any cases for which I can see
an 'obviously correct' fix.
But the reason I'm posting here is that there are some cases where the
correct/best behaviour isn't obvious to me. Most importantly, in the case
of what I'll call 'aggregate commands' such as commit and update - ie
those which request that one operation be done on multiple targets, each
of which can independantly fail or succeed - what should happen when the
operation succeeds on some target(s), but fails on some other target(s)?
The only thing I am sure about is that the exit status should be non-zero
in this situation, because zero means that *everything* succeeded.
For example, take a look at the final lines of
subversion/svn/resolved-cmd.c, in function svn_cl__resolved. That code
eats all errors from svn_client_resolved. Apart from the check and return
in 'SVN_ERR(svn_cl__check_cancel...', the function will always return
SVN_NO_ERROR. It'll even do that when every single 'resolved' operation
that the user requested has failed! I feel sure that that's wrong, but I'm
equally unsure what would be right here.
Here are some alternate ideas for what to do in this situation:
1. Immediately break out of the for loop and propogate the error upwards,
ultimately propogating the error up into the exit status of 'svn'. Some
target(s) will not have had the requested operation attempted on them,
because the operation failed on some earlier target. This would be
perfectly acceptable to me, but maybe not other people. Also it differs
from the existing behaviour of some aggregate commands.
2. 'Remember' the error somehow for later upward propogation, but continue
with other targets. All targets will always have the operation attempted
on them. Since more than one of them may have encountered errors, we must
choose which error(s) to propogate upward. Seems to me a bit bug-prone for
only a small usability gain.
3. Do either 1 or 2 depending on some user preference or '--stop-on-fail'
command line option or something - ie punt the decision about how to
handle this case to the user. Conditionals in error paths often don't get
tested adequately so this scares me a little. But such flexibility would
be nice to have. I would use such a switch from our build scripts, but not
when using svn interactively, for example.
4. Roll back all the operations on all of the previously successful
targets when the first failure occurs on some other target, so that the
entire aggregate command either wholly succeeds on all targets, or it
wholly fails leaving no change to any target. Sounds hairy. I don't see
any existing client-side sort of commit/rollback of aggregate commands;
I'm not even sure such a thing is possible.
So what's the intended behaviour?
Regards,
--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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 22 02:39:19 2006