Philip Martin <philip_at_codematters.co.uk> wrote on 11/07/2008 09:45:31 AM:
> > Philip Martin <philip_at_codematters.co.uk> wrote on 11/07/2008 06:57:25
AM:
> >> 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...
>
> It's not the source of the copy that is the problem, it's the
> destination:
>
> svnadmin create repo
> svn mkdir file://`pwd`/repo/foo
> svn cp -mm file://`pwd`/repo/foo file://`pwd`/repo/bar
>
> What does the copy command do? It creates directory /bar as a copy of
> directory /foo, yes? No! It created /bar/foo:
>
> svn log -rHEAD -qv file://`pwd`/repo
> ------------------------------------------------------------------------
> r3 | pm | 2008-11-07 15:28:56 +0000 (Fri, 07 Nov 2008)
> Changed paths:
> A /bar/foo (from /foo:2)
> ------------------------------------------------------------------------
>
> I didn't have exclusive access to the repository and somebody else
> created the directory /bar before I could make my copy. I did check
> before issuing the copy command, but it was a race and the other
> person's commit just sneaked in before my copy commit. Without
> exclusive access to the repository there is no way I can know what the
> copy command is going to do.
This is PRECISELY a reason why I want/need a --force flag!!!!!
Create it if needed, overwrite it if it exists. The svn cp
functionality is modelled around the unix cp command which would
do the exact same thing in your scenario above...
Adding support for this doesn't make any "broken" behavior any worse
(the user said to overwrite) and it makes the "check and overwrite"
operation atomic which is impossible from any wrapper script.
Do you have a better proposal for "fixing" cp functionality?
Complaints that it is broken in other ways do not help and should
not be a valid reason to reject simple beneficial behavior additions...
Kevin R.
Received on 2008-11-07 18:05:53 CET