On Sat, Jul 9, 2011 at 12:00 PM, wangbin <clif...@163.com> wrote: > Hi, > I will migrate a svn service from a old host a.com to another new host > b.com, the repository is more than 600G. > What's the best solution of lower downtime? > > Thanks a lot! > Wang,bin
There are numerous approaches, with tradeoffs. * Buy Wandisco's "MultiSite" software. Allow it to synchronize both sites, or preferably 3 sites, then turn off the old site. Costs money, but supports future migrations and failover, and does a very thoughtful job of keeping them in sync according to my discussions with them. * If both systems run the same version of subversion on similar architectures, and you're not doing a version update in the process, consider doing rsync between host 1 and host 2. You can pre-stage that, set host 1 to be "read-only" with a pre-commit.hook, do a final rsync, then activate the other host by re-enabling your pre-commit hooks. Polnt your users to the new repo, they can use "svn switch --relocate" comands to reset their working copies to the new repo, and the changeovers are minimal. If you can do a CNAME or DNS switchover with the same overall URL's, even better. Scheduling the switchover time is left to the reader. If you do this, your old host must NEVER, NEVER, NEVER be used again in write-mode. There are numerous others, such as pre-staging with "svnsync" to switch arachitures or refactoring of projects into different repositories, or finally getting things under $URL/project/trunk instead of $URL/trunk/project.. In that case, the UUID's of the repositories would be distinct, and switchover for clients is trickier. But that leaves you the opportunity to dump old ISO's and spurious branches and tags that contained passwords and things like that. Consider it an opportunity rather than a burden, if you've been hoping to do that.
