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.)
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?
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?
-Karl
---------------------------------------------------------------------
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 22:57:17 CEST