Matthew Sanderson writes:
>
> 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
Sounds great!
> this, or planning to do so soon? Am I duplicating effort?
I don't know of any. When you start working on this, you can mark the
issue as started.
> 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.
I think we agreed some time ago that we should return non-zero in this
mixed scenario. I'm +1 on that, anyway. (Means I like that solution).
> 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.
Every command that could produce warnings could set a flag in the
svn_cl__cmd_baton_t it receives. Then the main function would know to
return a non-zero exit code. For situations where the library call
takes multiple targets, we could use the notification mechanism to get
the warning tot the client. We already do that to some extent (see
how non-fatal locking errors are handled).
I've been meaning to address this issue for some time, but not gotten
around to it. I'll review patches that you provide and feel free to
ask more questions if you need to.
(On a side note, I'm not sure if resolved should ignore *all*
errors. Anyway,
it could use svn_cl__try().)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 22 11:35:40 2006