On Sep 26, 2008, at 12:07, Rob Hubbard wrote:
> In the past, I've encountered a problem with tag creation. If the SVN
> copy command is accidentally issued twice, something rather nasty
> 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
> This is perfectly reasonable. It's what you asked for. The behaviour
> matches what a shell copy (or cp) command would do. It's certainly not
> an SVN bug.
> (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.)
Well, the tags directory does have a special meaning to you and me:
it is a place where you copy things to but then never change again.
Install a pre-commit hook to allow adds but not modifications in the
tags directory and you solve the problem.
> The problem stems from the fact that the copy command means something
> slightly different depending upon whether the target already exists.
> An alternative possible cause of this problem is if two engineers
> the same tag at almost the same time.
Two engineers trying to create tag at the same time is a
communication problem; not Subversion's domain to solve that.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-27 03:22:25 CEST