No. We already have the case today that the working rev inherits from the
peg rev. Why? Because given the definitions of the things, that makes
sense most of the time. Your change adds a new behavior such that the peg
revision inherits from the working rev, but that's *exactly wrong* most of
the time. Consider the very common case of trying to see how the file
currently named foo.c looked in some old revision 15:
'svn cat foo.c_at_15' == 'svn cat URLOF(foo.c)@15 -r15', but both are
the wrong syntax for this type of query as they don't necessarily answer
questions about the same foo.c you asked about.
'svn cat -r15 foo.c' == 'svn cat -r15 URLOF(foo.c)@15', here again
incorrect because it might be querying the wrong line of history.
The only correct invocation in this world would be:
'svn cat -r15 foo.c_at_BASE', which is more obviously correct because
of the explicit peg revision which identifies lines of history.
But this is the same as the syntax most folks would use today for this
already, because ***we chose the right defaulting model for the most common
use-cases***:
'svn cat -r15 foo.c'
David Glasser wrote:
> 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
>>
>>
>
>
>
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-12-01 15:33:11 CET