[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: Branko Čibej <brane_at_xbc.nu>
Date: Thu, 27 Nov 2008 22:00:54 +0100

Martin Furter wrote:
>
>
> On Wed, 26 Nov 2008, [UTF-8] Branko Čibej wrote:
>
>> Quoting another poor user:
>>
>>> anyone who can explain what's happening, below?
>>>
>>> Somehow `svn ls` and `svn co` are failing to properly look at stuff in
>>> an old revision that was since removed...
>>
>>
>> This was quickly tracked down to the illogical discrepancy between the
>> revision specified by -r and the default peg-revision.
>>
>> I think it's time to admit that defaulting all peg-revisions to HEAD was
>> a horrible mistake; it implements the principle of least surprise in a
>> way that manages to be constantly surprising and confusing to most
>> users, including myself ... yes, almost every time I want to look at
>> some old stuff in the repo, I end up typing a command twice -- once the
>> way it /should/ work, and then once again the way it /does/ work, adding
>> an apparently extraneous duplicate peg-revision parameter.
>
> The first thing I thought is "me too". But that really only happens
> with deleted nodes.
>
> But after thinking about what happens if -r sets both, revision and
> peg-rev, I tried a few commands on a branch:
>
> $ svn log -r 33642 ._at_33642
> svn: REPORT request failed on
> '/repos/svn/!svn/bc/33642/branches/fsfs-pack'
> svn: '/repos/svn/!svn/bc/33642/branches/fsfs-pack' path not found
> $ svn ls -r 33642 ._at_33642
> svn: URL 'http://svn.collab.net/repos/svn/branches/fsfs-pack'
> non-existent in that revision
>
> I hope I used the right syntax here to simulate the
> peg-defaults-to-rev behaviour. If I did I guess we would end up with a
> more annoying default.

This is a very good point. Thanks for bringing it up; food for thought.

(And the first really constructive response in this thread, I'm sad to say.)

-- Brane

---------------------------------------------------------------------
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-27 22:01:39 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.