Philip Martin <philip_at_codematters.co.uk> wrote on 11/07/2008 06:57:25 AM:
> > Philip Martin wrote:
> >> kmradke_at_rockwellcollins.com writes:
> >
> >>> 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)
>
> Consider:
>
> svn cp URL/foo URL/bar
>
> if this command works a new revision is created but the user won't
> know what that revison contains. The only way to determine which of
> URL/bar or URL/bar/foo got created is to examine the repository after
> the commit. Without exclusive access to the repository it is
> impossible to predict the outcome of the copy. That's a terrible
> interface for anyone building tools on top of Subversion.
If you are concerned about the source revision, you can specify
it with both "svn cp -r REV URL1 URL2" or "svnmucc cp REV URL1 URL2"
In this case I know exactly what I copied... I'm still confused
how you can get unexpected behavior if you specify these...
> >>> 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.
>
> Although I still struggle to see why anybody would want it, I have
> already expressed a preference for adding an overwrite action rather
> than adding a force flag. I'd like the action to make directory
> overwrites work over all RA layers and I'd like to see a check to
> catch the current directory overwrite bug (since I don't think the
> server is going to get fixed in the near future).
There are the following use cases when an user wants to have
"sliding" labels:
1) Label does not previously exist and needs to be created.
2) Label already exists and needs to be moved.
Without a "--force" option I need to write a special case
scripting hack for my users for case #1. With it, I can just tell
them that "svnmucc --force cp REV URL1 URL2" will create it
if needed or move it if it already exists.
Using the scripting hack, I now need to deploy a common
scripting environment to 20k hosts. and make sure all
users know to use my special script. With the option I only
need to make sure they are using svn 1.6.
Let me take a stab at writing the patch to:
1) Check for existing copy targets and error if
they exist (to workaround the dav bug)
2) Add a new action "OV" to forcibly overwrite existing targets
(or just do an add if it does not exist)
For bonus points I may even add some tests! :)
Kevin R.
Received on 2008-11-07 16:23:44 CET