C. Michael Pilato wrote:
> David James wrote:
>
>>> A peg revision is THE way to specify a particular version of a
>>> particular
>>> object. The way I'd specify it is:
>>>
>>> svn propdel PNAME TARGET[@PEGREV]...
>>>
>>> Delete the property PNAME from the head revision of each TARGET.
>>> If PEGREV is specified, only proceed if the line of history from
>>> TARGET_at_PEGREV to TARGET_at_HEAD is unbroken and the property PNAME
>>> has not been modified in that interval.
>>>
>>> Similarly for "propset".
>>
>> Great points, Julian! After reading through your argument, I
>> completely agree.
>
> I'm not -1 on this or anything, but the UI seems ... "off" to me. 'svn
> pset /path/to/foo_at_34 pname pvalue -m "Some log message."' reads like
> "Change the value of property 'pname' on revision 34 of 'foo'". That's
> of course nonsensical, because you can't *change* the value of the
> property in that revision -- you can only make a new revision.
Hmm. There may be something in what you say. I was proposing that
svn pset url://to/foo_at_34 pname pvalue -m "Some log message."
means
"Set the property on a NEW revision of the object identified as
url://to/foo_at_34, and at the same time regard this revision 34 as the Base
Revision for the modification."
I can see that it does read a bit like it should mean
"Change the value in this old revision".
Whether that's confusing enough to warrant a different syntax, I'm not sure.
However, thinking more deeply on it (below), I conclude that although I was to
some extent conflating the concepts of Base Revision and Peg Revision, in fact
they fit very well together and the peg revision syntax is pretty much necessary.
> Also, if you go this route, then you absolutely should allow --revision
> to override the default operative revision (the peg revision) for parity
> with all the other subcommands that implement the peg-revision
> algorithm. In other words, we're back to --revision being the primary
> way to specify the based-on-revision for this propchange, with the
> typical chain of default values for that revision: it defaults to the
> peg revision's value, which defaults to HEAD for URLs and BASE for
> working copy paths.
So you're saying that the "base revision" should not be determined simply as
being equal to the "peg revision", but that instead it should be determined as
being equal to the "operative revision" (-r/--revision). I agree with the
former: "base" is not the same concept as "peg". But I don't agree that "base
revision" is the same concept as "operative revision" either.
I think the concept of "operative revision" presently only applies to read
operations. For a repository-side modification, would it mean the revision on
which to base the modification, or the revision in which the modification is
committed? Let's not go there.
Write operations are normally expected to occur in a WC. There, we have the
well established concept of the Base Revision upon which modifications are
made. The base revision is never explicitly specified in a modification
command, since there is never any doubt about it. (The result of the
modification, internally called the "working revision", is not explicitly
referred to either.)
Write operations directly on the repository have similar semantics: the Base
Revision is chosen to be the initial value of HEAD, a working revision is
constructed, and then it is committed as a new revision (failing if the Base
Revision is out of date by that time). However, in this case the problem is
there is some doubt about the choice of Base Revision (since HEAD may have
changed since we last looked), and we want to specify it explicitly.
Some write operations already perform a read ("merge", "copy", ...) and already
use "--revision" to specify the operative revision (or range) to read from.
A safe general solution (applicable to all commands that could modify the
repository) is a separate option like "--base-rev=N" or "--base-revision=N".
So, as the safe general form, let's consider:
svn pset [--base-rev=BASEREV] URL[@PEGREV] ...
The Base Revision is BASEREV which defaults to PEGREV. The Base Revision
determines which revision of the object this modification is to be applied to.
(We haven't yet specified in detail in what way the object is allowed to have
been modified since BASEREV. We still need to specify this behaviour,
carefully, taking account of directory bubble-up behaviour.)
PEGREV specifies the Peg Revision which defaults to HEAD. As with all commands,
the peg revision just gives an unambiguous context in which to interpret URL to
identify a specific object, bearing in mind that that object may have been
moved in the repository since the revision identified.
The optional PEGREV is essential in order for URL to identify an object
unambiguously. As David James said, once you've specified a Peg there is no
practical reason that we can imagine to specify a different Base.
Thinking how this scheme would apply consistently to a read-and-write operation
such as "copy":
Presently:
usage: copy SRC[@REV]... DST
New:
usage: copy SRC[@REV]... DST[@REV] [--base-rev=BASEREV]
Again, I don't see a need for the Base Revision to be specified separately.
It still feels to me like the "@PEGREV" syntax is just right for specifying
targets, and the only thing against it is the need to learn that "mofify
URL_at_REV" means create a new revision based on REV rather than modify REV in
place. I don't think that's too difficult or confusing a concept; novices will
sometimes stumble on it but not in a way that's very different from or worse
than all the other hurdles they have to master.
Therefore I'd propose just adding [@PEGREV] support to the target URL in all
commands that are to support this feature:
svn pdel URL[@PEGREV]
svn pset URL[@PEGREV]
svn pedit URL[@PEGREV]
svn copy SRC[@PEGREV]... DSTURL[@PEGREV]
...
Notice that "pedit" reads and writes a single object, and the notion of both
reading from "URL_at_PEG" and writing a new revision based on the same "URL_at_PEG"
makes total sense.
I'm still willing to hear any counter-proposals. The main ones I can think of are:
[--base-rev=BASEREV] URL[@PEGREV]
(as I sketched above, where BASEREV and PEGREV are usually the same, and
BASEREV should not be specified without PEGREV because it would be ambiguous)
[--base-rev=BASEREV] URL
(where BASEREV defaults to HEAD and is used both as the Base Revision and
as the Peg Revision for URL, instead of "@" syntax)
(And "--base-rev" would probably need a better name.)
Can anyone see a strong reason for or against any of these?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-27 14:54:01 CET