subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <>
Subject Re: upgrading server
Date Sat, 29 Jul 2017 09:24:25 GMT
On Tue, Jul 25, 2017 at 9:00 PM, Mark Phippard <> wrote:
> On Tue, Jul 25, 2017 at 2:00 PM, Andy So <> 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
>                              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:


View raw message