On Wed, 2008-08-27 at 16:56 -0400, Karl Fogel wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
> > No. It is by design that this function returns the entire peg-specifier
> > part of the input string, rather than a canonical peg specifier derived
> > from it. The callers rely on this.
> > Now, it's maybe not a great design, but that's how it is at the moment.
> > And the doc string is not clear on this point.
> So in this instance, the caller is simply using the returned values
> wrongly? (Forgetting for the moment the possibility of improving the
> design -- I'm just talking about whether the caller is working correctly
> with the API as it stands today.)
This instance being svn_client_args_to_target_array()? No, that's using
it correctly. It just splits off the peg-specifier part of the string
temporarily, canonicalises the rest, and the re-appends the
peg-specifier string, to leave a result string which is still properly
peg-escaped (i.e. may end with "@" or with "@PEGREV" or with neither,
just as it did on input).
> Who is supposed to be responsible for peg-rev escaping? That is, if
> someone puts "@" on the end of a path (presumably for the sole purpose
> of establishing that there is *no* peg rev here), what API is
> responsible for handling that?
svn_opt_parse_path() - the API that parses the string into a path part
and a peg. (Not this one that "splits" the string.)
I notice now that svn_opt_parse_path()'s doc string doesn't mention its
behaviour when just a trailing "@" is found, and furthermore the sole
example of this shown in its doc string appears to be wrong, showing
that the revision "base" would be returned in this case.
> I would have thought it would be svn_opt__split_arg_at_peg_revision().
> That is, it hadn't occurred to me to consider the final "@" to be "the
> entire peg-specifier part of the input string". Rather, I'd have
> considered it a marker that indicates that there is no peg-specifier
> here at all. Clearly I'm wrong, but I still don't quite understand what
> the system is supposed to be, then... Do you understand it?
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-27 23:11:10 CEST