Greg Stein wrote:
> Is a new datatype really needed? You've got two members, and one
> of those already has pretty sketchy multi-variant semantics.
A tuple of (path_or_url, peg_revision) is currently used throughout the
libsvn_client API as the main way to specify what versioned thing to operate
on. Having its (sketchy) semantics documented in one place, and having the two
pieces of the tuple kept together, is very useful.
As with the whole branch this is experimental. You'll have noticed I had
defined and started using a "svn_client_target_t" in this branch, holding this
info plus an operative revision plus the resolved location (repo, rev,
relpath). It was an earlier attempt at this sort of thing, but I've now
realized that was trying to do too much all together. Hence I'm trying a
simpler thing.
- Julian
> On Nov 1, 2011 8:12 AM, <julianf...@apache.org> wrote:
> > On the 'showing-merge-info' branch: Introduce a 'pegged
> > location' data type in the libsvn_client API.
[...]
> > +/** A "peg" is the location of a versioned node in a repository or in a
> > + * working copy, as specified by the client to libsvn_client.
> > + *
> > + * If @a path_or_url is a URL then @a peg_revision specifies the
> > + * revision at which the URL is to be looked up, and the peg revision
> > + * kinds 'base', 'committed' and 'prev' are invalid.
> > + *
> > + * Otherwise, @a path_or_url is a working copy path.
> > + *
> > + * @note About the meaning of a "peg revision" with a working copy path.
[...]
> > + */
> > +typedef struct svn_client_peg_t
> > +{
> > + const char *path_or_url;
> > + svn_opt_revision_t peg_revision;
> > +} svn_client_peg_t;
