On Sat, 17 Mar 2001, B. W. Fitzpatrick wrote:
> Mo,
>
> Excellent. I've applied your patch with the exception of the
> SVN_ERR_ALREADY_PRINTED, which I had to whip up myself (you didn't
> provide a patch to include/svn_error.h). This works very nicely, and I
> nthink it's definitely more flexible than what we currently have.
Doh! My apologies. I changed subversion/client and forgot
to add them to the patch.
Index: include/svn_error.h
===================================================================
RCS file: /cvs/subversion/subversion/include/svn_error.h,v
retrieving revision 1.86
diff -u -r1.86 svn_error.h
--- include/svn_error.h 2001/03/17 07:16:27 1.86
+++ include/svn_error.h 2001/03/17 23:30:09
@@ -44,6 +44,11 @@
SVN_ERR_MALFORMED_FILE,
SVN_ERR_INCOMPLETE_DATA,
+ /* This error code should be used when an error message has
+ already been printed. The svn_handle_error method would
+ simply print nothing an return in this case */
+ SVN_ERR_ALREADY_PRINTED,
+
/* The xml delta we got was not well-formed. */
SVN_ERR_MALFORMED_XML,
Index: libsvn_subr/svn_error.c
===================================================================
RCS file: /cvs/subversion/subversion/libsvn_subr/svn_error.c,v
retrieving revision 1.56
diff -u -r1.56 svn_error.c
--- libsvn_subr/svn_error.c 2001/03/02 22:17:15 1.56
+++ libsvn_subr/svn_error.c 2001/03/17 23:30:09
@@ -307,7 +307,11 @@
/* Is this a Subversion-specific error code? */
if ((err->apr_err > APR_OS_START_USEERR)
&& (err->apr_err <= APR_OS_START_CANONERR))
- fprintf (stream, "\nsvn_error: #%d ", err->apr_err);
+ {
+ if (err->apr_err == SVN_ERR_ALREADY_PRINTED)
+ return;
+ fprintf (stream, "\nsvn_error: #%d ", err->apr_err);
+ }
/* Otherwise, this must be an APR error code. */
else
I was going to simply return out of svn_handle_error()
when SVN_ERR_ALREADY_PRINTED was found. I was thinking
that what was needed was a more general sort of error
that told the system printing of the error message
had already been done. Your approach uses a specific
error indicating a wrong number of args. I guess I
really don't see that one way is really better than
the other so I would be happy with either.
> I'm probably going to take the help strings out of main and put them
> into the respective client files... there's no reason for it to be all
> lumped together in main.
I was under the impression that the subcommand usage text
needed to be part of the svn_cl__cmd_desc_t table.
How else would we lookup a subcommand by name and
then print it's usage? We need to support printing
the usage text in two ways:
1. When the user call the subcommand with the incorrect
number of arguments `svn delete`
2. When the user asks for the help text for a subcommand.
`svn help delete`
Mo DeJong
Red Hat Inc
Received on Sat Oct 21 14:36:26 2006