Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

List - Thanks for all previous replies

Nico,

I can assure you that the work is legitimate.   I support a consortium 
of 8 or so state health departments. They all use an application called 
IBIS (here's one version https://ibis.doh.nm.gov/).

I am working with Utah Dept of HHS, and Hawaii Data Warehouse who 
contracts with the Hawaii Dept of Health. Currently the content is 
stored in the SVN repository hosted in UT.  That server is managed by UT 
Dept of HHS, and because of state security I am not permitted to have 
login access to that server.  That server is scheduled to be turned of 
at the end of this month. Hawaii has offered to host the repository. So 
I am working with them to set it up.   UT proposed using the dump file 
which they would share via some network cloud storage.

I had asked the about svnsync, and am concerned that they may have some 
kind of high bandwidth or large "downloads" detection. I have not heard 
back from them so I am attempting to use what they propose.

I should be able to try loading this weekend, and see whether or not the 
load chokes.  If it does I will work with UT for other ways to migrate.

Thanks for you warning about large repos, and your suggestion.

On 6/7/2024 3:15 AM, Nico Kadel-Garcia wrote:
> On Fri, Jun 7, 2024 at 1:31 AM Lorenz via users
> <[email protected]> wrote:
>> Paul Leo wrote:
>>
>>> We need to migrate an SVN repository from CentOS 7, Subversion 1.94 to
>>> Ubuntu 24.04, SVN 1.14.3.
>>>
>>> We don't have any login access to the current server.
>>>
>>> The current hosting server plans to perform an SVN dump of the
>>> repository, and make it available through something like Google Drive.
>>>
>>> We would obtain the dump file and then use svnadmin load, importing the
>>> repository.
>>>
>>> There are only a few hooks that are currently used.  The main one being
>>> to force a commit message when committing.
>>>
>>> We will use Apache httpd and basic authentication for committing to
>>> repository, as in done currently
>>>
>>> We would change DNS to new server IP.
>
> "Missing login access" is not the same as "missing bacup access". If
> you can save the SSH hostkeys, and the TLS certificates which may be
> on the host for transfer to the new host, you probably want to do so
> to keep transfers consistent and avoid arguments about changed host
> specific keys. If you don't have backup access.... why are you
> responsible for this work? And are you planning a man-in-the-middle
> replication and replacement?
>
> If the work is legitimate, might I suggest using "svnsync" for the
> transfer, rather than svnad,om dump and restore? It won't preserve all
> your locally modified post or pre commit hooks, but what you describe
> is a simple setup, oddnesses done to those scripts should be recorded
> as Infrastructurre As Code fpr a production system.
>
> Unfortunately, if the repo has gotten too large over the years,
> svnadmin duump and restore, and svnsync, will choke to death before
> completion. This is what happens with the primary Subversion source
> repo, which can no longer be reliably replicated.
>
>
>
>>> I've read through the svnbook, and the above seems plausible.
>>>
>>> I am just wondering if anyone has some guidance and suggestions, since
>>> we are making a significant jump to newer version of SVN.
>>>
>>> Thanks for your help
>>>
>> You might want to retain the repository UUID, otherwise you would need
>> to re-checkout your working copies
>> --
>>
>> Lorenz
>>