[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: Stefan Haller <lists_at_haller-berlin.de>
Date: Fri, 28 Nov 2008 17:52:10 +0100

Mark Phippard <markphip_at_gmail.com> wrote:

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

I think both points are valid, and both can happen in practice.

This means that the only way to please everybody is to *try both*: first
default to HEAD (or BASE for WCs), and if the path doesn't exist there,
try r12 instead. This will do the right thing for people looking for a
now-deleted branch, and it will do the right thing for people looking
for either the new or old name of a renamed item.

The only situation where it might give wrong results is when an item was
renamed, and an unrelated item was later added with the same name. This
is probably unlikely enough that I wouldn't worry too much about it.

Stefan Haller
Berlin, Germany
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-28 17:53:08 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.