Migration depends on a lot of infrastructural constraints. a) do you have full access of the servers b) do you have virtualized systems, or plan to use on the new server. c) what is the network layout between the servers, lan/wan,etc. d) what is the allowed downtime. e) is there a need for "cleaning" the data
All of these and probably other constraints should carefully be checked before being able to guide into a specific direction. Amongst solution elements: As others stated, you can use svn specific tools like svnsync. An other approach would be more independent of svn: You can also use, filesystem or volume snapshots, if available. Stop the svn before taking the snapshot to be sure of a consistent snapshot. Then you can mount the repository snapshot to the new server. If everything is prepared upfront, then you should be able to migrate in just about seconds. Keep in mind, that you have a huge snapshot volume, since the snapshot volume will become your working volume. This way you can probably drastically bring down the downtime. Another way to minimize downtime is to run your server in a VM. In case you want just to migrate the server HW. You can use VM specific tools and means to easily migrate. I personally did even live migration of XEN VM in - fractions of a second - downtime. Snapshot as well as VM Technology has to be thoroughly planned before use. Regards Thomas -----Ursprüngliche Nachricht----- Von: Nico Kadel-Garcia [mailto:nka...@gmail.com] Gesendet: Samstag, 9. Juli 2011 20:42 An: Les Mikesell Cc: users@subversion.apache.org Betreff: Re: the best migrate solution of lower downtime On Sat, Jul 9, 2011 at 12:54 PM, Les Mikesell <lesmikes...@gmail.com> wrote: > On 7/9/11 11:30 AM, Nico Kadel-Garcia wrote: >> >> 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. > > You can use svnsync to do the copy, then change the uuid to match the old > one as long as the final transaction matches - that is you do not do any > commits during or after the last sync run. It is much slower than rsync'ing > the underlying files (and doesn't take hooks), but might be worth doing if > the original repo started with an old version of subversion. I've used that. It's potentially more dangerous, especially because svnsync can be used with repository splitting.
