On Fri, 2008-07-04 at 13:58 +0100, Julian Foad wrote:
> 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?
Filed issue #3231 "Peg revisions on WC paths are handled inconsistently"
<http://subversion.tigris.org/issues/show_bug.cgi?id=3231>, as I can't
investigate this now.
- 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 15:43:30 CEST