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

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
example:

> 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
revision.

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/