views:

759

answers:

5

I have a large Subversion repository with nearly 15gb of data spread across ~500,000 files. Now I need to checkout this repository to a remote host which would take days to complete.

The host I'm checking out to already has a complete copy of the data in the repository. But seeing as the files weren't checked out directly from the repo, they do not constitute a working copy (no ".svn" folders).

I'd like to avoid copying all this data across the network, especially when it already exists on the target host. Is there a trick I can use that will turn a preexisting directory into a working copy without replacing the local files with identical copies from the repository?

Thanks!

+3  A: 

There is the relocate command: http://svnbook.red-bean.com/en/1.1/re27.html

EDIT: If the local files aren't linked to a repository then you could create a local repository, import the files into it and then use the relocate command.

Alternatively if you have physical access to both machines you can you check out the repository locally and then copy the files to the remote machine via a external HD.

Jonathan Parker
I don't see how you could use relocate here. relocate only updates metada in the .svn folders. There are no .svn folders according to OP.
Wim Coenen
See my edit for a workaround for this.
Jonathan Parker
I doubt this will work, because you can only relocate to a repository with same repository UID
Peter Parker
The documentation I linked to above says: If the working copy still reflects the same repository directory, but the location of the repository itself has changed, then use svn switch --relocate.
Jonathan Parker
A: 

You could just checkout the repository locally, then transfer only the .svn directories (careful, they contain copies of the workspace files, obviously you don't want to copy those). That should work, as you would have the exact files of a correct working copy.

Of course you'd have to write some kind of script to transfer the .svn files. On a Unix system you could do it with find and friends.

sleske
-1 If he has around 500,000 files imagine to move all the .svn folders 'carefully'?
victor hugo
Of course you would use some script. The "careful" was to warn of a potential problem when writing such a script.
sleske
I considered this, but as Victor pointed out this could be pretty tedious with such a large repo. Also, the ".svn/text-base" folders of the working copy contain pristine copies of all files in the repo, so even copying just the .svn folders will still require a complete copy of the data.
weston
Yes, of course, that's why I mentioned a script. I'm not expecting anyone to copy it all by hand :-/. And of course you wouldn't copy the stuff under text-base, you'd only create the emtpy directories '.svn/text-base', then copy the existing files from the destination into text-base. Yes, that might require a bit of programming, but it still beats recopying 15 GiB.
sleske
A: 

I don't believe there's a solution without transferring those 15 GBs to the destination. It would probably be faster and easier to copy the repository there and do a local checkout.

Gleb
Well, funny you suggest this because I tried checking out just a local working copy on the server itself. Even a local checkout takes well over a day to complete and this wouldn't include the time it would take to dump/copy/load into a new repository on the remote host.
weston
It may mean that subversion isn't the right tool for you...
Gleb
+1  A: 

You could try using rsync if you already have a working copy under svn control somewhere else on the network.

This isn't such a bad idea but, as mentioned in another comment, the .svn/text-base folder contains pristine copies of all your repo files, so rsync would end up copying all the data over anyway. You could possibly tell rsync to ignore replicating "text-base" and then script something to populate the "text-base" once the .svn folders are synced.
weston
A: 

Use:

svn co http://myRepo --force

Danita