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)
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.
The only circumstance where we might not have immediate local access (or
indeed any access) to the object referred to by "foo_at_BASE" is when foo
is a local, still-uncommitted copy. But that is something we can
determine locally too, of course.
> (b) A peg rev and an operative rev are both in effect in every command.
> Each of them has a default, but I'm not sure we're entirely clear or
> consistent about what those defaults are. I think operative-rev is
> normally supposed to default to peg-rev.
Sure, we may have some inconsistencies, but I'm not sure they affect
this particular case.
> By this line of reasoning, "svn proplist foo_at_BASE" should throw an
> error: "A peg revision is not allowed on a WC path".
>
> Or does "foo_at_PEG" mean "-r PEG foo"? And if so, what does "-r X foo_at_PEG"
> mean?
I hope the above answers this question precisely.
-Karl
---------------------------------------------------------------------
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-04 17:54:30 CEST