Accidental double tag copy
From: Rob Hubbard <rob.hubbard_at_softel.co.uk>
Date: Fri, 26 Sep 2008 18:07:19 +0100
Dear SVN Users,
I have a suggestion / feature request for SVN.
First: the problem
In the past, I've encountered a problem with tag creation. If the SVN
Suppose you have a project called "tag_copy_twice" with a few files in a
version-controlled trunk (in some repository svn://repos/) as follows:
You create a tag for version 1.0 as follows, e.g.
$ svn copy -m"tag v1.0" "svn://repos/tag_copy_twice/trunk" \
All is still well and good. You now also have these files:
Accidentally issuing the tagging command a second time, you end up with
This is perfectly reasonable. It's what you asked for. The behaviour
(I think this is a special case that TortoiseSVN warns about: changes to
areas with "tag" in the URL. I don't think that's the right approach for
SVN: paths should not have special meanings.)
The problem stems from the fact that the copy command means something
the same tag at almost the same time.
Fortunately, if you accidentally issuing the tagging command a third
svn: Path 'tag/v1.0/trunk' already exists
so it doesn't get worse still.
Second: comparison with Bash cp
Now consider the following Bash shell script (this is nothing to do with
#rm -Rf to ### dangerous!
### ordinary copy
### copy using -t or --target-directory==DIR
### copy using -T or --no-target-directory
find "to" -iname "*.txt"
This outputs something like this (I've rearranged and spaced out the
cp: accessing `to/targ1': No such file or directory
Third: suggested solution
It would be great if SVN copy had these
The above switches would help, as they would make the required behaviour
explicit. However, this wouldn't solve the whole problem, as the copy
Thus perhaps further switch
might be useful for URL to URL copies. The meaning of this would be to
Perhaps a new (versioned) property on directories
svn:final (or svn:sealed or svn:read-only)
in conjunction with a copy switch
--mark-final (or --seal or --mark-read-only)
could be implemented. (As usual, I suppose --force should overcome the
I dare say that these suggestions are not ideal, but there is something
This is an archived mail posted to the Subversion Users mailing list.