In the past, I’ve encountered a problem with tag creation. If the SVN copy command is accidentally issued twice, something rather nasty happens.
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:
./tag_copy_twice/trunk/dir1/dir1file.txt ./tag_copy_twice/trunk/dir2/dir2file.txt ./tag_copy_twice/trunk/file.txt
You create a tag for version 1.0 as follows, e.g.
$ svn copy -m"tag v1.0" "svn://repos/tag_copy_twice/trunk" "svn://repos/tag_copy_twice/tag/v1.0"
All is still well and good. You now also have these files:
./tag_copy_twice/tag/v1.0/dir1/dir1file.txt ./tag_copy_twice/tag/v1.0/dir2/dir2file.txt ./tag_copy_twice/tag/v1.0/file.txt
Accidentally issuing the tagging command a second time, you end up with this:
./tag_copy_twice/tag/v1.0/dir1/dir1file.txt ./tag_copy_twice/tag/v1.0/dir2/dir2file.txt ./tag_copy_twice/tag/v1.0/trunk/dir1/dir1file.txt ./tag_copy_twice/tag/v1.0/trunk/dir2/dir2file.txt ./tag_copy_twice/tag/v1.0/trunk/file.txt ./tag_copy_twice/tag/v1.0/file.txt
This is perfectly reasonable. It’s what you asked for. The behaviour matches what a shell copy command would do. It’s certainly not an SVN bug. In fact, the problem exists between the keyboard and chair (PEBKAC), as they say.
An alternative possible cause of this problem is if two engineers create the same tag at almost the same time.
I don’t know of a solution to this problem. It may be possible to prevent the problem on the server side with a suitable commit hook script. I don’t know of an SVN copy safety option such as –don’t-create-top-directory. I don’t see a discussion of this on the SVN users mailing list <http://svn.haxx.se/users/>.
If you know of an elegant solution to this problem, please let me know.
Fortunately, if you accidentally issuing the tagging command a third time, SVN issues an error:
svn: Path 'tag/v1.0/trunk' already exists
so at least it doesn’t get worse still.