[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: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 26 Nov 2008 14:18:19 -0500

On Wed, Nov 26, 2008 at 2:11 PM, Branko ibej <brane_at_xbc.nu> wrote:
> I already posted an example of an IMHO wrong default for the URL_at_HEAD
> case. Now here's one for the WC_at_BASE case:
> svn log
> This doesn't show commits newer than the BASE of the current directory
> -- *even* if the latest commit was yours but happened not to bump thad
> directory's BASE. Now if that isn't an unexpected default, I don't know
> what is.

In this case, you are confusing the peg and operative revisions. The
peg revision does not control what revisions that log returns, it
instead canonically defines the path whose history you want to see.
For the WC, I do not think there is ever a scenario where BASE would
not be right.

I think the problem with your HEAD argument is that you are still
basing it on your assumptions from a given scenario. You give this

> 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

To me that really does not make sense. For this to even be an issue
you have to be saying that the path svn://example.com/frob either does
not exist at all in HEAD or at a different location. OK, that is
pretty common. But which let's say it has been renamed. Are you more
likely to know the name and location where it existed at r12 or at
HEAD? It is typically a lot easier to know about HEAD than some past

There are always examples where each of the possible defaults makes
more sense to a user. I think having a policy where the default is
consistent and predictable is defensible and makes sense.

Mark Phippard
Received on 2008-11-26 20:18:33 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.