On Wed, Feb 27, 2008 at 5:53 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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?
I think your proposal is good, but for the specific case of "propset"
I think the pegrev should be *required*.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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 19:15:46 CET