+1 all over that.
So --base-rev would not be required, but *would* be available for folks to
use for protection. I mean, realistically speaking, humans would never
bother with such a thing. But scripts around 'svn' would be very wise to do so.
David James wrote:
> On Fri, Feb 22, 2008 at 11:44 AM, <kmradke_at_rockwellcollins.com> wrote:
>> "Mark Phippard" <markphip_at_gmail.com> wrote on 02/22/2008 01:34:23 PM:
>>> 2008/2/22 Kevin Radke <kmradke_at_gmail.com>:
>> > > This is my first attempt at a patch to add URL support to the propset
>> > > and propdel subcommands of svn. In doing so, I also noticed that
>> > > propedit did not support multiple URL arguments correctly.
>> > >
>> > > I needed URL functionality for propdel, since we had a repository
>> > > had the svn:special property set for a file that was not special. I
>> > > unable to create a working copy with this file due to this error, and
>> > > I was also unable to delete the property since you previously needed
>> > > a working copy to delete properties. I was able to use this modified
>> > > propdel to delete the incorrect property directly in the repository.
>> > What is the stuff about the -r parameter for? We would never allow
>> > you to go back in time and delete or edit a property, only HEAD. Is
>> > it being used for some other purpose?
>> > I am just going by the email, have not looked at the patch.
>> Needed a way to specify a "base revision", because of the possible
>> race condition between looking at the properties and then
>> performing a command directly on the repository.
>> We kicked around a --base-rev parameter in another thread, but
>> it was easier for me to "overload" the meaning of -r here.
>> Not using -r and using some other parameter is definitely a
>> (probably less confusing) option.
>> We could also assume "HEAD" (others didn't like this)
>> Is peg revision syntax appropriate? (no idea on this)
> I think that 'svn propdel' and 'svn propset' should assume the
> "base-rev" is HEAD. Here's why:
> - If the file currently exists, svn rm already assumes that the
> base-rev is HEAD. So svn propdel should do the same when the property
> - If the file does not exist, svn import already assumes that the
> base-rev is HEAD. So svn propset should do the same when the property
> does not exist.
> Based on the above, there is only one situation where you need to
> specify a base revision -- if you are trying to modify (but not
> delete) a property which is already present in the repository. In
> other cases, you can specify a base revision if you want to have
> additional safety constraints, but there is no need to do so.
> Some more comments:
> - If a pegrev is explicitly specified, the base rev should default
> to the pegrev.
> - 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.
> I can also think of a few places outside of the 'svn prop*" commands
> where base revs might be useful:
> - In future, I think we should extend the 'svn rm', and 'svn import'
> commands to also support base revisions. In both cases, this would
> allow for additional safety when you want to be sure you aren't
> overwriting someone else's changes. In the case of 'svn import' if you
> specify a base-rev, you can actually overwrite an existing file in the
> repository with a new version.
> - In future, we might also want to extend 'svn cp' and 'svn mv' to
> support base revs and a --replace option. This would allow, in theory,
> for users to overwrite a file or directory which is already present in
> the repository with a new version in a single commit.
> Based on the fact that base revs might be useful in future in commands
> which already accept the '-r' option, I think that we should use a
> different option for 'base-rev', such as --base-rev.
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-02-23 02:48:29 CET