kfogel@tigris.org writes:
> New Revision: 6524
> Log:
> Fix issue #1384: If 'svn mkdir' errors because the target already
> exists, then have it suggest 'svn add' as an alternative.
>
> * subversion/clients/cmdline/mkdir-cmd.c
> (svn_cl__mkdir): Wrap error from svn_client_mkdir, if EEXIST.
With this commit, the user now sees:
$ subversion/clients/cmdline/svn mkdir already-existing-target
subversion/clients/cmdline/mkdir-cmd.c:72: (apr_err=17)
svn: File exists
svn: Try 'svn add' or 'svn add --non-recursive' instead?
subversion/libsvn_subr/io.c:1501: (apr_err=17)
svn: can't create directory 'already-existing-target'
$
This is more helpful than before, but it would be even better in this
order:
$ subversion/clients/cmdline/svn mkdir already-existing-target
subversion/clients/cmdline/mkdir-cmd.c:72: (apr_err=17)
subversion/libsvn_subr/io.c:1501: (apr_err=17)
svn: can't create directory 'already-existing-target'
svn: File exists
svn: Try 'svn add' or 'svn add --non-recursive' instead?
$
In fact, as I thought about it, I couldn't come up with a case where
one wouldn't want the outermost error printed last. That would also
match the intuitive order of things: first X went wrong, which caused
Y, which finally resulted in our printing Z, where Z is "commit
failed" or "update failed" or "try this other command" or whatever.
How would people feel if error.c:handle_error() printed errors out in
that order? I think it would improve our error messages a lot.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 21 21:47:32 2003