[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance

From: Ryan Schmidt <subversion-2016_at_ryandesign.com>
Date: Fri, 28 Jul 2017 01:15:31 -0500

On Jul 27, 2017, at 14:23, James H. H. Lampert wrote:
>
> 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.

Sounds plausible. An empty pre-revprop-change hook script would allow any revprop change, which you may not want. It's probably possible to write a more-specific script that would allow only the changes svnsync needs and disallow others.

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

svnsync doesn't care what system user account you use. You would probably want to pick the username that the server process will use. If you're serving with Apache, that'll be a username like nobody or httpd or apache.

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

svnsync is probably best, since it allows you to easily incrementally mirror a live read/write repository to another server. It can be slow but once it's done it makes it very quick to switch from the old server to the new one with minimal downtime. Some of the other methods require you to make the source repository read-only or take it offline for the duration of the migration, which could take hours or days depending on how large your repository is.

> I'm not seeing a lot about copying configuration files or hook scripts. Is that just a matter of sending them over?

Pretty much. You may need to edit the files if the setup of the new server differs from the old one. New versions of Subversion may also offer more features than old versions, which may affect your scripts or configuration.

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

If you're using Apache to serve the Subversion repository, on both the old and new systems, then you're right, Subversion users don't care about server system user accounts; they only care about user accounts as defined in whatever authentication you've set up for the repository in Apache.
Received on 2017-07-28 08:15:51 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.