Julian Foad <julianfoad_at_btopenworld.com> wrote on 02/26/2008 10:08:02 AM:
> kmradke_at_rockwellcollins.com wrote:
> > james82_at_gmail.com wrote on 02/22/2008 04:03:04 PM:
> >> Some more comments:
> >> - If a pegrev is explicitly specified, the base rev should default
> >> to the pegrev.
> Yes. But take this further: If a pegrev is specified, the base rev
> the peg rev. I can't see any reason to specify the base revision
> (Specifying a base rev older than the peg wouldn't achieve anything.
> a base rev newer than the peg would, theoretically, be useful if youknew
> object had been moved/renamed since the peg but you didn't know the new
> But until Subversion is able to track forward across renames, it
> can't achieve
> anything useful in this case either.)
> >> - If you leave out the revision, or explicitly specify "-r HEAD" or
> >> file_at_HEAD for 'svn propset', svn propset should check to see if the
> >> property already exists in the repository. If the property already
> >> exists, an error message should be printed which explains that a
> >> base-rev is required.
> > Since you can't set a property on an old revision, I'm not convinced
> > a peg revision specification should even be possible...
> A peg revision is THE way to specify a particular version of a
> 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".
I had originally liked using @PEGREV instead of --base-revision. This
would definitely make the patch smaller, since a new option is not
I'd like to create a patch that is liked by the majority, but I'm not
convinced we have a consensus yet.
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-26 18:09:28 CET