Greetings.
My employer has put me on a project of moving our SVN and Trac servers
from the old Windows Server 2003 box on which they're currently running
over to a Google Compute Engine instance.
To that end, I've set up the instance using Bitnami's canned Trac image,
which includes SVN 1.9.5 (r1770682) and Trac 1.0.15 (our old SVN server
is 1.5.0, r31699, and our old Trac server is 1.0).
I've got a test repository set up, and I've arranged access via both
https: and svn+ssh: protocols, which I then spent a few hours testing
from Eclipse.
But I'm not the one who set up the original SVN and Trac environments in
the first place, and so what little I know about administration on these
products is what I've picked up over the past few weeks.
Now, Trac's wiki page on the process of a dual migration,
https://trac.edgewall.org/wiki/TracMigrate
seems to be pretty straightforward on the subject of migrating Trac, but
the section on migrating SVN is not so.
They recommend setting up a "pre-revprop-change" script with nothing in
it but the initial "shebang", for each target repository, and then using
"svnsync" to migrate the repositories. It also assumes the existence of
an "svnsync" user-ID on the target system, which (at least assuming it's
an operating system user-ID) we don't currently have.
Everything else I've read, especially The SVN Book, says to use
"svnsync" only for mirroring, and instead migrate using some combination
of "svnadmin dump," "svnadmin load," "svnrdump," and "svnrload."
I'm not seeing a lot about copying configuration files or hook scripts.
Is that just a matter of sending them over?
And I don't quite understand how this whole business impacts the authors
of commits. Does SVN care whether the author of a commit is a user known
to SVN or to the operating system? I've already copied an "authz" file
from one of the existing repositories into the test repository, and
given the current users Apache user-IDs and passwords, but that's all,
so far.
--
James H. H. Lampert
Touchtone Corporation
