Philip Martin <philip_at_codematters.co.uk> wrote on 11/06/2008 05:03:16 PM:
> kmradke_at_rockwellcollins.com writes:
>
> > Problem is, you have to handle a whole bunch of corner conditions
> > because the check and action are no longer atomic. I.E. it could
> > exist, you try and delete it, but someone already beat you to
> > it, but then you just try and cp it, but someone beat you to
> > it and copied something else, so then you try again, etc.
>
> Your script can loop, trying one command and if that fails try the
> other.
>
> Take your example of "moving a tag". If I try to move a tag and it
> does not exist I probably mistyped the tag name, so the command should
> fail rather than create the wrong tag. If I try to create a tag that
> already exists I probably mistyped the tag name, so the command should
> fail rather than overwrite the tag. How often do you move or create a
> tag and not know whether or not it exists? If other people are
> creating/removing tags that conflict with yours do you really want to
> overwrite them?
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"...
</rant>
For example, in Unix, cp -f exists to make it an easier operation.
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. 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. 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.
Long term this will be much more effort and pain than adding
native support and does not help out the community.
Which of these options have the highest possibility of acceptance:
1) Modify svnmucc cp to allow a --force behavior
2) Modify svn cp to allow a --force behavior
3) Create a new tool based on svnmucc, add --force behavior
and contribute to contrib?
Kevin R.
Received on 2008-11-07 00:53:17 CET