On Wed, 2008-07-02 at 18:18 -0400, Karl Fogel wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
> > It depends whether the operative revision defaults to the peg revision.
> > It doesn't, here. If it did, then we'd get the behaviour I expected and
> > you expect.
> >
> > I couldn't remember which way round it's meant to be, which is why I
> > assumed I must have been wrong, but now you mention it maybe the
> > operative rev IS supposed to default to the peg rev. Yes, I think that
> > makes sense...
> >
> > In that case, there IS a bug.
>
> I don't understand what the phrase "operative revision defaults to the
> peg revision" means, actually.
>
> Here's how I think of it:
>
> An operative rev of X (-rX) means "Take this path (that is, a URL, in
> the end), and then walk back along its history to whatever it was in rX,
> and that's the object in question".
>
> A peg rev of X (@X) means "Go to revision X, then walk down to the
> specified path -- that's the object in question."
>
> The reason they can be different is that things can be copied/renamed.
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.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.
(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.
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?
- Julian
---------------------------------------------------------------------
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 14:58:28 CEST