On Tue, Jul 25, 2017 at 9:00 PM, Mark Phippard <markp...@gmail.com> wrote: > On Tue, Jul 25, 2017 at 2:00 PM, Andy So <a...@vitria.com> wrote: >> >> We have an old subversion version 1.4.3 (r23084) running on Solaris. >> >> We would like to upgrade to use new hardware on Linux based OS (CentOS >> 6.9), possibly version 1.8.x or 1.9.x >> >> >> >> Our plan is to installed and configure the latest SVN on CentOS 6.9. Then >> go through dump and load of the repository as described in various online >> post and documentations. The repository is quite large…guessing the size to >> be in the order of 20-40GB >> >> >> >> Before we start undertaking such tasks >> >> 1. Does anyone know if there are there any problem/gotcha in >> migrating the repository? >> >> 2. Does anyone know how long it would take to export the repository >> of this size? This will give us an estimate how long to schedule down time >> and cut off time. >> >> >> >> Thanks for any insight. > > > > Dump and load is a good idea because it lets the repository be rewritten > using the newer code and repository format which will give you a smaller > repository that will run a little faster. That said you do not HAVE to > dump/load. You have other options: > > 1. Just move the repository folder to the new server. Perhaps using tar and > then moving the archive. > > 2. Instead of using dump/load, use svnsync. This gives all the benefits of > the dump/load but allows you to shrink your downtime to almost nothing. > Just svnsync the repository to the new server. This will probably take a > long time, but it does not matter since the original server can be running > while it happens. At the time of your choosing, do a final svnsync, and > then shutdown the old server and use the new one. > > 3. Do option 1 now and then do a dump/load or svnsync at some future time > that is more convenient for downtime. It will probably run faster since it > is on new and better hardware too. > > There are some gotchas no matter what: > > 1. Does the new server have a new hostname or do you intend to update DNS > to point to new server? If you are not doing the latter, then all of your > existing working copies and scripts have to be modified for the new server. > Also any use of svn:externals property has to be modified. > > 2. With an old repository there is a good chance you will run into bugs in > your data that cause svnsync or load to fail. There are workaround for > different failures but be prepared to run into them and account for finding > the solutions. SVN 1.8 and 1.9 have added various options to let you > workaround some of the known bugs. A common problem is having svn: > properties that are not UTF-8 encoded or do not have LF line endings. > svnsync has this option to work around the encoding problem: > > --source-prop-encoding ARG : convert translatable properties from encoding > ARG > to UTF-8. If not specified, then properties are > presumed to be encoded in UTF-8. > > And it automatically fixes the LF problems. > > svnadmin load does not have any options to fix the problems, but you can add > the --bypass-prop-validation option to ignore them and just carry the > problems into your new repository.
Indeed, dump/load is a bit more limited than svnsync regarding normalization. Also, be careful: both dump/load and svnsync do not migrate your hook scripts, config files and locks (server side locks of the svn:needs-lock type). I've just extended the FAQ entry about dump/load with some of the known caveats, and explained a procedure to do dump/load with minimal downtime. See: http://subversion.apache.org/faq.html#dumpload -- Johan
