"Robert S. Sfeir" <firstname.lastname@example.org> writes:
> While teaching a subversion class yesterday, we came across an
> interesting anomaly with svn copy which I believe is a bug.
> Here is how to set it up and reproduce the behavior.
> a new repository with the following structure is needed for testing:
> Once you have the repository buit with this structure, create a tag
> of each SubDir1 into tags1 in the tags directory and watch what
Thanks for the report. You were teaching a class on Subversion? Wow,
now we are truly The Establishment. :-)
> svn copy myProject/trunk/Dir1/SubDir1 myProject/tags/tag1
> A tags/tag1 (I see that file1.txt is in this directory, which is
> what I expect)
> svn copy myProject/trunk/Dir2/SubDir1 myProject/tags/tag1
> A tags/tag1/SubDir1 (for some reason in this case it creates
> SubDir1 with file2.txt in it)
Well, sure. trunk/Dir2/SubDir1 contains file2.txt, so why wouldn't
that be inside the tag created here?
> svn copy myProject/trunk/Dir3/SubDir1 myProject/tags/tag1
> Fails because SubDir1 already exists.
This is expected. It tries to create 'tag1', but 'tag1' already
exists. Fine: it falls back to creating 'tag1/SubDir1', but *that*
already exists as well. So it must error.
The 'fileN.txt's have nothing to do with it, AFAICT.
> However as you can see by testing it is that the behavior is
> different for the first 2 copy commands and the third behaves like
> the second. Why is subversion changing its behavior on copy? Should
> it not provide some kind of consistency and not take a guess on how
> to best copy a directory or directory content?
It shouldn't guess, it should behave according to predictable rules,
which it is doing.
Does this explanation make sense?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Apr 12 18:20:50 2005