[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Clearing up some API ambiguity (@-syntax)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-08-30 05:53:21 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.