On Fri, 28 Sep 2007, Eric Gillespie wrote:
> dlr@tigris.org writes:
>
> > Author: dlr
> > Date: Fri Sep 28 13:36:13 2007
> > New Revision: 26841
> >
> > Log:
> > Fix issue #2880, 'svn commit --changelist NO_SUCH_CHANGELIST' should warn.
>
> Hmm:
>
> 0 trunk% svn st --changelist fo
> subversion/svn/main.c:1788: (apr_err=205000)
> svn: Try 'svn help' for more info
> subversion/svn/status-cmd.c:229: (apr_err=205000)
> svn: no such changelist 'fo'
>
> 205000 is SVN_ERR_CL_ARG_PARSING_ERROR. I prefer
> SVN_ERR_UNKNOWN_CHANGELIST, but it also looks like the error is
> coming from different levels between these two commands. I
> wonder if that's right...
I agree that the error behavior should be consistent across commands...and
preferably, handled at single layer.
Oddly, 'commit' seems to handle changelists different than other commands,
most of which use svn_client_get_changelist() to fill a list of changelist
targets in the command-line client which is then fed to a library routine.
'commit', on the other hand, takes a changelist name and finds the changelist
targets inside libsvn_client. Ben, what's the reasoning for this (e.g.
structure of the commit harvesting logic)? Can/should we change this?
I've changed the error code and messages to be consistent across both
'commit' and the other commands, but the output is still different (and
likely the exit code, too), because the other commands are returning a
hard error, while 'commit' is supressing an error and spitting out a warning.
Which way should we go here?
$ svn ci --changelist=is-not-here
svn: warning: Unknown changelist 'is-not-here'
$ svn st --changelist=is-not-here
subversion/svn/status-cmd.c:230: (apr_err=200024)
svn: Unknown changelist 'is-not-here'
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Sat Sep 29 06:43:26 2007