David Glasser wrote:
> On 8/29/06, C. Michael Pilato <cmpilato@collab.net> wrote:
>> * However, if we expect the endstuffs to *not* be encoded (like,
>> they aren't *really* part of the URL), then there's a bigger
>> problem to solve in that opt_to_target_array() needs to stop
>> encoding that stuff (and that's a trickier change to pull off).
>
> Perhaps opt_to_target_arrayN should be returning an array of pointers to
>
> struct {
> const char *path;
> svn_opt_revision_t start_rev;
> svn_opt_revision_t end_rev;
> }
>
> instead?
I've strongly considered this as well. Though there's no need for an
end_rev -- these are actually (path, peg_rev) tuples that we're parsing.
From a parsing perspective, I love the idea. The bum thing is that 99%
of the time, there's no explicit peg_rev provided. This means the
function is returning a list of paths in a fashion that is incompatible
with the list-of-paths that so many of the client functions accept.
So we could take this another step further. Make your recommended
structure (say, svn_location_t) more commonplace, make
svn_opt_target_array() return a list of those things, and make all the
svn_client* functions that currently accept a list of const char * paths
and one or two peg revisions accept a list of them.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Aug 30 05:54:21 2006