I think there is a hole in our definition of "peg revision" that is
contributing to the confusion.
The syntax "URL_at_PEGREV" is clear. It means "In the repository as it was
at revision PEGREV, look up the path-in-repos part of URL." No problem.
The syntax "WCPATH_at_PEGREV" is, however, non-obvious and we keep making
statements that assume a meaning of it without being sure that we all
understand the same.
Two main possibilities are:
a) "Apply the peg revision to WCPATH's current URL."
Note the path-in-repository of the object WCPATH at its current BASE
revision[1]; call this path P. Operate on the object at path P in the
rPEGREV snapshot in the repository (if it exists).
b) "Trace the object's history back to PEGREV."
Trace the line of history from the specified local object (WCPATH_at_BASE).
Operate on the object that is in that line of history in the rPEGREV
snapshot of the repository (if it exists).
Normally in "svn", a WCPATH argument identifies the version-controlled
object associated with that local-disk path. With this in mind, (a) does
not make much sense. For example, if the repository has ever undergone a
major restructuring such as renaming "/proj/trunk" to "/project/trunk",
then attempts to reference history from before the rename will always
fail with this syntax. That doesn't sound like the right user interface
model.
However, we sometimes wish a relative WCPATH argument would be
interpreted as a relative URL instead. Relative to the absolute URL of
the current WC directory, of course... but which URL? The one where its
ancestor lived at rPEGREV, perhaps. Several possibilities. Perhaps that
is what we are really wishing for when we think of interpretation (a).
Interpretation (b), on the other hand, uses the PEGREV argument like an
operative revision. The initial peg is BASE[1], by the very definition
of a working copy node. This interpretation is nasty because it will
involve two historical jumps to get to the command-line operative
revision, which seems unnecessarily complex.
I wonder whether in fact the peg revision of a WC path should be
acknowledged as being BASE[1] by definition, and because of that it
should be an error to specify any peg revision explicitly on a WCPATH
argument.
- Julian
[1] Actually, though we keep saying BASE, it would be better to base the
definitions on the WORKING version, to make things like scheduled copies
and renames work as I would expect. Rather than taking P from WCPATH's
BASE URL, we should take P to be the path-in-repos at which WCPATH will
exist if it is committed.
[2] Or possibly a descendant, if we support some kind of forward
tracing.
On Mon, 2008-12-01 at 09:32 -0500, C. Michael Pilato wrote:
> 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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=983381
Received on 2008-12-12 13:53:23 CET