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.
>> 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
>> 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
> 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
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... :)
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