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.
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
> *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
> [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):
> 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 | email@example.com | http://www.davidglasser.net/
Received on 2008-11-28 20:11:07 CET