I've got an svn working copy of close to 300MB. I'm across the internet from the source and I didn't want to check the whole thing out again. I had originally checked it out with svn+ssh:// but I wanted to switch to svn://. I needed to switch because svn+ssh takes longer than just svn://. The ssh part needs to reconnect with every svn * command, and I didn't want to pay the 2-3 seconds of that ssh negotiation. There might be a way to use a persistent ssh session, but that would look dumb, providing no beneft.
I thought maybe svn switch might do the trick, but after some trial and error, and actually reading The free svn online book show that switch doesn't work the way I thought. While trying stuff out I also looked at --relocate. There's an example of svn switch --relocate here, but that doesn't do what I need either. I'm not moving anything to a branch or elsewhere in the repository, I actually want to change the protocol used to communicate with the repository.
Finally, I fell back on rsync. I use rsync a LOT. It solves a lot of problems that I run across at work (and in the occasional consulting job). For this task, I first did an svn co svn:// checkout *at* the same computer as the repository. This was just so I'd have a working copy with svn://, normally, I use file:/// there.
Once I'd got a checked out copy using svn://, I rsynced that with my remote copy (which used to be svn+ssh://). There was probably something slightly wrong with what I did. It correctly synced the subdirectory .svn directories to use the new protocol, but the root didn't get changed. So I rsynced that .svn directory separately.
Total bandwidth cost of the rsync was around 4MB received and 2MB sent. Since the whole checked out working copy is 327MB, that's quite a savings. It actually took less time to do the rsync than my previous attempt, which was to tar and compress the remotely checked out svn:// working copy. I was then going to scp or rsync the archive over. When the archive blew up to 60MB though (and still going), I gave up on that. I certainly didn't want to copy over 60MB if there was some other way.
No comments:
Post a Comment