RFC: Untangling the peg revision knot (was: A preliminary study of non-contiguous transformations in the Hilbert space of Alexandrian solutions)

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
Received on 2008-11-26 04:54:57 CET