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
<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
