[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] make svnmucc consistently overwrite copy targets

From: Kevin Radke <kmradke_at_gmail.com>
Date: Thu, 06 Nov 2008 22:54:31 -0600

Philip Martin wrote:
> kmradke_at_rockwellcollins.com writes:
>>> kmradke_at_rockwellcollins.com writes:
>> I'll admit some of the examples are a little contrived. Our use
>> case is fairly unique, but one must handle these corner conditions
>> gracefully, even if they aren't the expected mode of operation.
>> <rant>
>> However, I've been getting a little tired of people saying
>> "just write a script". This fails to address multiple clients and
>> platforms that would need to be handled.
>> I've submitted a patch, gathered feedback, been willing to
>> change the patch, but I still hear "just write a script"...
> You hear that from me because in my opinion that's the best solution
> for your particular problem. "Other opinions are available" [smile at
> camera].
>> </rant>
>> For example, in Unix, cp -f exists to make it an easier operation.
> And Unix mkdir doesn't support it. The fact that svnmucc replaces
> directories when using mod_dav_svn might well be a server bug.

FYI, just last week, the svn cp behavior was justified because it was
meant to work like the unix cp command (not mkdir) or dos copy...

>> Yes, the user could have manually written scripts around cp to
>> handle the manual unlinking if needed, but there was a perceived
>> usefulness to allowing overwriting an existing file in one step.
>> There have been multiple requests on the users list to be
>> able to easily overwrite an existing tag.
> svnmucc allows users to overwrite tags, they don't need your patch. I
> originally wrote it to do more or less exactly that.

I was trying to make it easier to use. Since you didn't like the
default silently overwrite, I asked if adding an option would
be better. I believe an option is definitely better than writing a
wrapper script and maintaining it for multiple platforms.

>> Allowing a "force"
>> operation doesn't force anyone to use it, but does make
>> it easier to use for a certain group of people that need
>> it.
> You describe your use case as "fairly unique" so I guess it's a very
> small group.

I support 3000+ users. Most of these would benefit from this behavior.
There have been a number of similar user list questions, but I can't
say a majority of open source users want it...

>> I believe the functionality gains outweigh the minor
>> added complexity, or I wouldn't have been willing to create
>> an acceptable patch.
>> I do not want to maintain wrapper scripts for multiple platforms.
> There are several cross platform scripting languages.

The point is those are needless added client dependencies. Ever
try to get a consistent cross platform scripting language installed
for 20k client machines?

>> Long term this will be much more effort and pain than adding
>> native support and does not help out the community.
> It's certainly less work for you if we maintain it :)

I do already have partial commit rights and I am willing to help
support it! :)

>> Which of these options have the highest possibility of acceptance:
>> 1) Modify svnmucc cp to allow a --force behavior
> It was a mistake for svn to use --force, it should have been
> --force-xxx or --force=xxx.

I see --force-log already for cp, anything else? I'm confused.
I was talking about unix cp --force behavior. Don't particularly
care what the svn option would be named.

> How would this option behave when svnmucc combines multiple cp
> actions? What about rm when the target doesn't exist? cp when the
> source doesn't exist? cp when the parent of the target doesn't exist?
> All of these things could get forced but I just don't see the need.
> Are you going to make directory overwrite work over the other RA
> layers?

I'm assuming it already does work when passed the REPLACE action.
The previously mentioned potential DAV bug is when the ADD action
was passed. I'll be honest and I don't regularly test anything
other than DAV in our environment.

If the option is well documented, the behavior for multiple command
failures could be mentioned. Maybe just "--ignore-errors". Any
sub command that fails will be silently ignored and will not stop
the rest of the sub commands from executing? Sorta a "buyer beware"

>> 2) Modify svn cp to allow a --force behavior
> svn cp with URLs already has some unpredictable behaviour, I'm not
> sure whether force would make it better or worse :)

This confuses me as well too. You specify a source rev and path
and a target path. What is unpredictable about that? (other
than possibly passing HEAD as rev which could change)

>> 3) Create a new tool based on svnmucc, add --force behavior
>> and contribute to contrib?
> That would be silly.

But you are essentially telling me to re-implement (and possibly not
distribute) custom wrapper scripts. I believe that is silly.

> I remain unconvinced about your patch; perhaps somebody else will
> venture an opinion?

I don't mind not using the patch as is. I'm looking for guidance
on what is acceptable behavior so I can create a new patch.

I'm up to about a half dozen options now. I hope all my thoughts
aren't bad... :)

Kevin R.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-07 16:31:09 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.