> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 12 August 2002 22:11
> striker@tigris.org writes:
> > + * If STRICT is non-zero, then if we encounter a path that is missing
> > + * from the wc, or is obstructing a resource in the wc, we'll return an
> > + * error. STRICT should be zero if we're updating, as the update will
> > + * catch any non wc path errors (and properly deal with files that are
> > + * in the repository but missing from the wc for whatever reason).
>
> Do you also want to say what happens when STRICT is not set?
Well, I would, but since I'm on holiday in a few hours and offline for
2 weeks I'll defer that to someone else ;)
In short: it returns appropiate status codes for the entries that would
error when STRICT is set (svn_wc_status_absent and svn_wc_status_obstructed).
> > + if (strict)
> > + /* ### Not sure if this is the correct error code to use */
> > + return svn_error_createf (
> > + SVN_ERR_WC_NOT_DIRECTORY, 0, NULL, pool,
> > + "assemble_status: "
> > + "'%s' is obstructing a versioned resource",
> > + path);
>
> I think maybe SVN_ERR_WC_PATH_NOT_FOUND? Just based on the error
> description string, it seems like it might more appropriate. In any
> case, whichever error code you choose, probably should make the public
> documentation of the function state the error and the circumstances
> under which it is returned.
*nod*
> > + if (strict)
> > + /* ### Not sure if this is the correct error code to use */
> > + return svn_error_createf (
> > + SVN_ERR_WC_UNEXPECTED_KIND, 0, NULL, pool,
> > + "assemble_status: "
> > + "'%s' is obstructing a versioned resource",
> > + path);
>
> Seems like a good choice to me.
>
> > + if (statstruct->text_status == svn_wc_status_obstructed)
> > + {
> > + /* ### Do we need to invent a new error code for this case? */
> > + return svn_error_createf (SVN_ERR_CLIENT_UNVERSIONED,
> > + 0, NULL, pool,
> > + "'%s' is in the way of the resource "
> > + "actually under revision control.",
> > + name);
> > + }
>
> Yeah, I think so. The problem is more like "OBSTRUCTED_STATUS" or
> something... ?
Ok. You are aware that this changes the error codes below the client error
code block (they all are bumped 1).
> > --- trunk/subversion/clients/cmdline/status.c (original)
> > +++ trunk/subversion/clients/cmdline/status.c Mon Aug 12 12:13:47 2002
> > @@ -73,6 +73,9 @@
> > case svn_wc_status_conflicted:
> > text_statuschar = 'C';
> > break;
> > + case svn_wc_status_obstructed:
> > + text_statuschar = '>'; /* ### Come up with a better moniker */
> > + break;
>
> Maybe `!' ? Or `~' ?
>
> I think `>' is not good because it implies a directionality that isn't
> there...
I just picked one. I didn't want to overload '!' since that means absent.
Any character is ok by me, which is why I couldn't come up with a good one :)
> -Karl
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 12 22:47:18 2002