Hi,
I had a 'funny(?)' collision when experimenting with SVN
while a colleague experimented with the same repository:
I tried to restore a deleted folder using somethign like
svn copy -r N http://somewhere/rep/Test http://somewhere/rep/Test
not knowing that my colleague created (or restored) an equally named
"Test" folder meanwhile there.
which, after svn update, left me behind with a new copy of Test as Test/Test
- quite surprising (and ~250MB of testfiles duplicated there).
the SVN documentation says the following:
>>
If browsing your deleted directory isn't enough, you can always bring it
back. Resurrecting data is very easy in Subversion. If there's a deleted
directory (or file) that you'd like to bring back into HEAD, simply use svn
copy -r to copy it from the old revision:
$ svn copy -r 374 http://svn.example.com/repos/branches/calc/my-calc-branch
\
http://svn.example.com/repos/branches/calc/my-calc-branch
Committed revision 376.
<<
so I tried this on my repository:
Test> cd Project/Test
Test> [some files already exist in Test here]
Test> mkdir Folder_X
Test> [can put some files into Folder_X here]
Test> svn add Folder_X
Test> svn commit Folder_X -m "AddX"
Adding Test\Folder_X
Committed revision 43.
Test> svn delete Folder_X
Test> svn commit -m "DelX"
Committed revision 44.
when I use the command on the DELETED file, like
Test> svn copy -r 43 http://svn.local/repos/Project/Test/Folder_X \
http://svn.local/repos/Project/Test/Folder_X -m
"RestoreX"
Committed revision 46.
then everything works fine, and I get the deleted folder back.
-but- if i use the -same- style of command on the -existing- "Test" folder,
then I get a whole new copy of Test within Test.
Test> svn copy -r 43 http://svn.local/repos/Project/Test \
http://svn.local/repos/Project/Test -m "RestoreTest"
Test>svn update
produces a directory/repository structure like the following:
Test/Test
Test/file_A.txt
Test/file_B.txt
Test/Test/file_A.txt
Test/Test/file_B.txt
and if I repeat the command a second time without deleting that Test/Test
folder i get
the error message:
Test> svn copy -r 43 http://svn.local/repos/Project/Test \
http://svn.local/repos/Project/Test -m "RestoreTest-2"
svn: Path 'Test/Test' already exists
( which is ofcourse true, but was not intended at all )
I guess svn tries to work as smart as unix "mv"
Test> mkdir Foo
Test> mkdir Bar
Test> mv Foo Bar
which REPLACES Foo with Bar, if Bar is empty
or moves Foo -into- Bar if Bar already has content
or if you put a slash at the end of Bar:
Test> mkdir Foo
Test> mkdir Bar
Test> mv Foo Bar/
then it definitely moves the folder Foo -into- the folder Bar/
I tried to use "svn mv" with and without slashes at the end and with and
without "/Test"
on the destination name but
it doesnt seem to make a big difference, I end up with a copy in Test/Test
or with an error message that the folder Test/Test (or /Test exists.
Maybe svn should support something like mv does
( --target-directory=DIRECTORY )
or at least distinguish that extra slash at the end?
It seems a bit strange if something different happens, depending on if a
folder was deleted
or still exists in the HEAD revision.
consider you perform that "copy" and someone else created that folder on the
head revision
meanwhile. You won't like what you'll see when you update back to HEAD.
At least -I- ended up with another 250MB copy of my 250MB Test-stuff,
because someone else just created a "Test" folder there a few seconds before
:-)
Using svn commands that operate on URL's and modify/commit the main-HEAD
revision
immediatedly should probably be avoided at all - since they tend to leave
the repository
in some "I don't know for sure if someone else modified the main-HEAD repos
right now
and if it still looks the same while i type that svn..URL command.
But using these remote/URL commands on "my very own repository branch" is a
BIG
advantage when working with the repository and over a slow internet
connection :-)
have a nice day
:-)
======
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 28 04:59:16 2004