On Wed, 17 May 2006, Garrett Rooney wrote:
> On 5/17/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> >Garrett Rooney wrote:
> >> + if ((peg_revision->kind == svn_opt_revision_base
> >> + || peg_revision->kind == svn_opt_revision_committed
> >> + || peg_revision->kind == svn_opt_revision_previous)
> >> + && targets->nelts == 1)
> >
> >I feel the logic for validating and handling a peg ought to be common among
> >many commands, and factored out. If you could have a bit of a look for
> >such
> >commonality, that would be great.
Julian, consolidating this code sounds Good, +1. Care to file a
(bite-sized?) task in the tracker?
> >Note also that "@PREV" is not a valid peg specifier: "local/path@PREV"
> >would
> >imply looking up "local_path" in a revision which does not exist in the
> >local
> >file system (and "URL@PREV" is obviously invalid). Similarly, we can
> >decree
> >that "@COMMITTED" is not valid (even though it identifies a tree in which
> >the
> >item was at the same location as it is now). Only "@BASE" and (implied)
> >"@WORKING" are valid pegs on a local path. I've been meaning to write up a
> >specification for peg revisions that states this. This might simplify your
> >conditional expression.
>
> I'm not convinced @PREV or @COMMITTED are invalid. It's just a matter
> of converting them to a url/rev pair and then doing exactly what we
> would do with any other peg revision argument...
...
Would this operation use information from the WC, rather than
contacting the server? Seems like doing the latter would result in a
race condition...
If we're not contacting the server, the semantics of using data from
the WC in conjunction with URLs could be confusing to users.
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Thu May 18 19:20:32 2006