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

Re: "proplist" wrongly interprets "@BASE"

From: Daniel Shahaf <d.s_at_daniel.shahaf.co.il>
Date: Sat, 5 Jul 2008 08:55:30 +0300 (Jerusalem Daylight Time)

Karl Fogel wrote on Fri, 4 Jul 2008 at 11:53 -0400:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
> > That's not quite how I think of it. Do we have this documented? I
> > remember trying to write it up a few months or years ago.
> >
> > Two pertinent things in the way I see it are:
> >
> > (a) The peg rev is the revision of the repository in which to first look
> > up the specified path.
>
> Right -- that's exactly what I think too.
>
> > Either that or we need to define what It doesn't
> > make much sense to specify a peg rev on a WC-path, because a WC-path can
> > only be first looked up in the local disk file system, and then it
> > refers to the "working" proto-revision and not an existing repository
> > revision. Before finding the path on disk, we wouldn't even know in what
> > repository to find any particular revision. So "foo_at_123", "foo_at_HEAD" and
> > "foo_at_BASE" are meaningless. Only the hypothetical "foo_at_WORKING" makes
> > sense and is redundant. I don't believe we're agreed or consistent or
> > enforcing this at all, however.
>
> No, remember that a working copy path can be unambiguously resolved to a
> URL (and thence to an in-repository path). This resolution can even
> happen locally, without talking to the repository.
>
> Thus, for "foo_at_BASE":
>
> 0. Resolve "BASE" to an actual revision number (easy to do locally)

By looking at the current revision of 'foo' (which may differ from the
current revision of its parent); e.g.,

    % svn co -r50 $URL wc -q
    % svn up -r51 wc/iota
    R iota
    % svn cat iota_at_BASE

currently resolves BASE to r51 (not to r50).

> 1. Find the URL for "foo" (also easy to do locally)
> 2. Strip the repository prefix from that URL (also easy to do locally)
> 3. Now we have the in-repository path, so...
> 4. ..."foo_at_BASE" means "the object at the in-repository path we just
> calculated, reached by walking down to that path from the root of
> the revision tree for revision number represented by BASE".
>
> No ambiguity there; in fact, I'm unable to think of any other
> interpretation that makes sense.
>
> Since the working copy path is by definition up-to-date as of its BASE
> revision, we don't actually have to contact the repository to get that
> object. It's just... you know... the pristine base of foo. We have it
> in our hands.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-05 07:55:48 CEST

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.