[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

From: Mark Mielke <mark_at_mark.mielke.cc>
Date: Fri, 28 Nov 2008 12:24:02 -0500

Stefan Haller wrote:
> 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.

I think this is presuming that a person is entering the command and they
know what they are looking for. If it's a computer, or if the person
might be making a mistake, the correct result may be to fail - because
the file really doesn't in that context.

There is no perfect answer here. We have multiple dimensions, and we
don't know what the user is thinking.


Mark Mielke <mark_at_mielke.cc>
Received on 2008-11-28 18:24:19 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.