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"
option.
>> 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