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.
> *Proposal B*
*snip*
> we'd introduce
>
> -r REV1[:REV2][@PEG]
> -r @PEG
> -c REV[@PEG]
I like that proposal and I guess it will make URL parsing a lot simpler.
> *Or* we could introduce
>
> -r REV1[@PEG1][:REV2[@PEG2]]
>
> and the single-peg variant would become one of
>
> -r REV1[@PEG][:REV2]
> -r @PEG[:REV2]
I prefer the first syntax. If I see "-r REV1_at_PEG:REV2" I'd probably always
wonder what peg-rev is used for REV2.
Just my comments as a subversion user.
Martin
---------------------------------------------------------------------
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 21:44:08 CET