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

Re: RFC: Untangling the peg revision knot (was: A preliminary study of non-contiguous transformations in the Hilbert space of Alexandrian solutions)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 26 Nov 2008 14:27:31 -0500

Branko Čibej wrote:
> Yes, that is exactly what I'm proposing. Leave the algorithm alone -- it
> works and is certainly necessary. But the current defaults for peg
> revisions are sometimes horribly wrong, to the extent that the simplest
> commands produce unexpected results.
>
> For example, take the example of "svn ls"; I expect this:
>
> svn ls -r12 svn://example.com/frob
>
> to be equivalent to this:
>
> svn ls -r12 svn://example.com/frob_at_12
>
> but a) it's not (*quite* unexpected) and b) why should I have to write
> the rev and peg both if they're the same?

You shouldn't have to write both, and you don't. The problem is that too
many people expect -r to do what @ exists to do. It's a simple matter of
(as I said) not understanding the application's definitions of "peg
revision" and "working revision". Peg revisions are about object identity;
working revisions are about an object's particular state in time.

In the situation you've quoted, you need only provide a single revision, but
it has to be the correct one for your need. If you need to know about the
/frob that lives in revision 12 (a question of identity), you do:

   svn ls svn://example.com/frob_at_12

We assume that when you ask about the /frob that lives in revision 12, you
(by default) have chosen that starting point because the *state* of the
object in revision 12 is of interest, too. That's why the working revision
(-r) defaults to matching the peg revision (@12).

If you need to know about an old state of the object currently (in HEAD)
located at /frob, you do:

   svn ls -r12 svn://example.com/frob[@HEAD]

I suspect that for every example you can come up with where someone might
expect one thing, there are other folks who expect the opposite. Rather
than confuse everyone by making every subcommend do something unique with
its peg- and working-revision syntax, we decided to unify the syntax across
the tool and trust users to actually learn that tool and understand what
they are attempting.

Yes, some users are too lazy to learn the tool to this extend. Some just
get by with using -r so often instead of @ because the results are often the
same, and then when the need for @ really shows up, they don't remember what
to do. And some will never understand any of this because the whole idea of
"lines of history" and such are just over their heads altogether.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-11-26 20:27:36 CET

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.