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_at_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
Received on 2019-11-07 14:41:20 CET