Re: upgrading server

On Tue, Jul 25, 2017 at 9:00 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Jul 25, 2017 at 2:00 PM, Andy So <akso_at_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