On Tue, Feb 26, 2008 at 8:08 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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 should BE
> the peg rev. I can't see any reason to specify the base revision separately.
>
> (Specifying a base rev older than the peg wouldn't achieve anything. Specifying
> a base rev newer than the peg would, theoretically, be useful if you knew the
> object had been moved/renamed since the peg but you didn't know the new name.
> 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 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.
In my earlier email, I also discussed extending the 'base revision'
support in future to work with other commands that delete or overwrite
files, such as 'svn rm', 'svn import --replace', 'svn cp --replace',
and 'svn mv --replace'. Fortunately, in all of these cases, pegrevs
are not yet supported for the target, so if we do want to add base rev
support to these commands, we would not have any backwards
compatibility issues. (Note that the --replace options for 'import',
'cp' and 'mv' are theoretical future features.)
Here are some examples:
svn rm $REPO/trunk/somefile_at_1000
svn import --replace somefile $REPO/trunk/somefile_at_1000
svn cp --replace $REPO/trunk $REPO/branches/dj-experiment_at_1000
svn mv --replace $REPO/branches/dj-experiment $REPO/trunk_at_1000
All of the above examples use pegrevs to explicitly specify that you
only want to replace or delete the target if it has not been changed
since rev 1000. This seems pretty reasonable to me. I actually like
the peg rev syntax better than the base-rev syntax now that Julian has
explained it to me.
Cheers,
David
---------------------------------------------------------------------
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 19:07:02 CET