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