Branko Čibej [mailto:br...@apache.org] wrote:
> 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:
The destination ambiguity always was a bug magnet. It's a problem as old as cp.
These days cp, or at
Many thanks to all who responded and explained the behaviour!
Great mailing list!
Am 07.11.2019 um 15:02 schrieb Daniel Shahaf:
Branko Čibej wrote on Thu, 07 Nov 2019 13:41 +00:00:
$ mkdir -p foo/bar
$ touch foo/qux foo/bar/baz
$ cp -R foo zzz
$ cp -R foo zzz
FWIW, creating the tag with
On Thu, Nov 7, 2019 at 8:19 AM 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.
It's not a bug. The last component of the destination path for the copy can
be interpreted two
Branko Čibej wrote on Thu, 07 Nov 2019 13:41 +00:00:
> $ mkdir -p foo/bar
> $ touch foo/qux foo/bar/baz
> $ cp -R foo zzz
> $ cp -R foo zzz
FWIW, creating the tag with svnmucc would give that same E160020 error
after the first time:
% svnadmin create r
% svn mkdir -qmm file://$PWD/r/{trunk,tags}
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
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:
-
