On Fri, Jun 7, 2024 at 1:31 AM Lorenz via users <users@subversion.apache.org> 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 >
