5

I have a normal SVN structure:

http://server/DEV/Project/trunk
http://server/DEV/Project/branches

I then branch off with the following command:

svn copy -m "message" "http://server/DEV/Project/trunk@123" "http://server/DEV/Project/branches/rel123"

Everything works great, and the content of /trunk@123 is placed under the new branch path /branches/rel123. All good.

Added : /DEV/Project/branches/rel123 (Copy from path: /DEV/Project/trunk, Revision, 123)

The problem:

If someone accidentally executes the branch off again, I expect it to fail with "svn: E160020: Path 'rel123' already exists". However it does not fail.

Repeating the same svn copy command in-fact copies the /trunk to /branches/rel123/trunk

Added : /DEV/Project/branches/rel123/trunk (Copy from path: /DEV/Project/trunk, Revision, 123)

So now, I end up with /branches/rel123 that contains all the files off the trunk, plus the extra folder "trunk" (/branches/rel123/trunk) that also contains all the same files off the trunk.

I have tried:

I've tried terminating the paths to force SVN to understand this is the absolute directory name, but no luck (i've stripped out http://server part in below examples)

svn copy -m "message" "/DEV/Project/trunk@123/" "/DEV/Project/branches/rel123"
svn copy -m "message" "/DEV/Project/trunk/@123" "/DEV/Project/branches/rel123"
svn copy -m "message" "/DEV/Project/trunk@123" "/DEV/Project/branches/rel123/"
svn copy -m "message" "/DEV/Project/trunk@123/" "/DEV/Project/branches/rel123/"
svn copy -m "message" "/DEV/Project/trunk/@123" "/DEV/Project/branches/rel123/"

Anyone experiencing this? Is this a known issue? Any workarounds to prevent this "branch inside a branch" mistake?

Slav
  • 27,057
  • 11
  • 80
  • 104
  • 1
    I have the exact same problem. And the answer "don't do that" below is not helping. Did you solve this ? – Eria Sep 06 '16 at 07:56
  • @Eria nope. I control this through strict process now: Jenkins jobs do all the branching/reintegration and I control the Jenkins permissions. But the underlying issue remains unsolved – Slav Sep 09 '16 at 04:48
  • Exact same problem here. I have automated creating a tag (svn copy trunk tag/)... and doing that twice should fail, not just create another 'trunk' directory inside an existing tag :( – dokaspar Jun 26 '17 at 12:38

1 Answers1

1

It's a feature. It lets you do things like:

svn move *.txt docs

to put all .txt files into a subdirectory.

This mirrors how any shell's "mv" or "move" or "cp" or "copy" or "xcopy" or "robocopy" command works.

Ben
  • 8,725
  • 1
  • 30
  • 48
  • For `mv` or `cp` commands, if I explicitly add a trailing `/` at the end of the path, it forces the command to treat the path as a folder, without ambiguity. Any source to documentation where it's explained as a "feature"? – Slav Aug 21 '14 at 13:01
  • But you can do: `cp -R mydir/ myotherdir` to create myotherdir, and then repeat the command to copy the directory inside, yes? SVN mirrors the shell's copy commands here. Acting otherwise would be far more unexpected. The solution to your problem is, "don't do that". – Ben Aug 21 '14 at 14:59
  • 1
    I can't prevent developers from accidentally branching twice, without removing their ability to create branches in the first place (which is required for developer/feature branches). So "don't do that" is not a solution – Slav Aug 21 '14 at 15:07
  • You can't prevent developers from accidentally deleting the entire trunk either, if they use `svn mv` instead of `svn cp`, or merging the wrong direction, or any number of other careless mistakes. So either you get really fancy with your pre-commit hooks; you expect your developers not to be careless; or you correct the mistake when you find it. – Ben Aug 21 '14 at 17:38