Maybe I could apply some more thinking here, but my initial thought is
"fuck ya!". The peg shit screws me up. It was very disturbing to
return to svn to find that specifying old revisions didn't work at ALL
like I would expect. Dug in, and found the peg stuff. Agreed that it
generally doesn't work as expected.
On Nov 25, 2008, at 19:54, Branko Čibej <brane_at_xbc.nu> 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.
>
> I can already hear the cries, "but, our compatibility rules ..."
> Indeed
> yes, but I don't think we ever promised to be eternally compatible
> with
> bugs.
>
> *Proposal A step 1*
>
> Change the defaults for all commands that accept peg revisions to
> something that is obvious and logical. For example, commands that only
> accept a single revision in -r (such as list and checkout) could use
> that value as the peg-revision default.
>
> The output of "svn help" would be extended to describe the per-command
> defaults.
>
> [Note for strict-compatibility-rules aficionados: this change in
> defaults *could* be disabled from .subversion/config. I'm not saying
> it
> should be, but it's fairly trivial to do so. It *should not* be
> controlled with a new command-line option; we have @HEAD for that.
> Scripts that care should be using explicit peg revisions already.]
>
> *Proposal A step 2*
>
> Change the peg-revision defaults in libsvn_client. This would require
> revving some 15-20 functions, at first glance.
>
> I do not propose to change peg-rev defaults in lower-level libraries,
> and certainly not in the wire protocols.
>
> *Proposal B*
>
> Change the syntax for peg revisions on the command line. I've always
> felt that appending @foo to a file name or URL is a bad idea; in the
> case of URLs, it causes confusion with embedded usernames, and the
> escaping rules for @-in-filename are non-obvious.
>
> Instead I propose that the syntax of -r and -c be extended with peg
> revisions. Instead of the current
>
> -r REV1[:REV2]
> -c REV
>
> we'd introduce
>
> -r REV1[:REV2][@PEG]
> -r @PEG
> -c REV[@PEG]
>
> For the really nasty "svn diff -rA:B URL_at_PEG1 URL2_at_PEG2", I'd consider
> allowing @PEG1:PEG2; so that would become
>
> svn diff [-r [A[:B]][@PEG1[:PEG2]]] URL URL
>
> That's quite complex, but it should be a relatively rare pattern. And
> it's not more complex than the current syntax.
>
> *Or* we could introduce
>
> -r REV1[@PEG1][:REV2[@PEG2]]
>
> or, more precisely (where \R represents any valid revision speciifer):
>
> /((@\R)|(\R(@\R)?))(:\R(@\R)?)?/
>
> and the single-peg variant would become one of
>
> -r REV1[@PEG][:REV2]
> -r @PEG[:REV2]
>
>
> Thanks for patiently reading all the way to here.
>
> Yes I could find some time to implement these changes, or a subset of
> them. Either proposal could also be a nice self-contained SoC
> project ...
>
> -- Brane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
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-26 05:22:09 CET