Re: "proplist" wrongly interprets "@BASE"

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.

In this case, you said foo_at_BASE, so:

Find @BASE (that's easy, just the base revision of 'foo'). Walk down
that revision tree, along the path for foo, until you find foo. That
object is the foo we want. It is different from the modified version of
foo in the working copy (also known as foo_at_WORKING).

Of course, in this case, it can all be done on the client side, because
we know that foo exists at that path in that revision -- the working
copy just magically knows this :-).

---------------------------------------------------------------------
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-03 00:18:59 CEST