Here's a relatively straightforward suggestion:
"If the user specifies only one of 'peg rev' and 'operative rev', the
other defaults to the one specified."
Honestly, I can never remember which direction the defaulting goes.
This rule would make it easy, while still preserving the ability to
set them separately.
--dave
On Tue, Nov 25, 2008 at 10:54 PM, 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
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Received on 2008-11-28 20:11:07 CET