On 07.11.2019 14:16, Roger Périat wrote:
> Hi all
>
> Not sure if this is a bug or not.
>
> Doing a svn copy twice to same destination, does create an unexpected
> subfolder in destination.
>
> 1) first step
>
> (The tags folder exists and is empty)
>
> svn copy file:///D:/tmp/myrepo/trunk file:///D:/tmp/myrepo/tags/v1 -m
> "this is v1"
>
> What we see:
>
> - v1 is created in tags by this command
>
> - v1 contains a copy of trunk after this command
>
> - All ok until now.
>
> 2) second step
>
> Issuing the same command once more, I would expect an error saying the
> destination folder ('v1') already exists. But this is not the case,
> the command ends normally.
>
> svn copy file:///D:/tmp/myrepo/trunk file:///D:/tmp/myrepo/tags/v1 -m
> "Redoing the tag v1, without deleting the tag before."
>
> What we see:
>
> In the tags/v1 subfolder a new folder is created by this command,
> named ‘trunk’ which contains a copy of the trunk. URL of new folder:
> /tags/v1/trunk
>
> If I issue the command once more, the command fails with E160020 (with
> text Path file:///D:/....v1/trunk already exists)
>
>
> Why does the svn copy command not fail at step 2?
>
> Subversion 1.12.2 running here
>
> Thank you for your time!Because that's how 'svn copy' is supposed to work, and is also documented. It works the same way as a recursive copy on a filesystem on Unix: $ mkdir -p foo/bar $ touch foo/qux foo/bar/baz brane@zulu:~/src/test$ find foo foo foo/qux foo/bar foo/bar/baz $ cp -R foo zzz $ find zzz zzz zzz/qux zzz/bar zzz/bar/baz $ cp -R foo zzz$ find zzz zzz zzz/qux zzz/foo zzz/foo/qux zzz/foo/bar zzz/foo/bar/baz zzz/bar zzz/bar/baz -- Brane
