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

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.

This doesn't refer to a unix user id, just the username and password used to authenticate to the source repository. It can be any username (not necessarily 'svnsync'). Just make sure that it has read access to the entire repository that you are svnsync'ing
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."

While svnadmin dump/load is the recommended path for migrating repos to a newer version, svnsync does pretty much the same thing. You just need to use the newer versions of the svnadmin and svnsync binaries (which are installed in your target system).
I'm not seeing a lot about copying configuration files or hook scripts. Is that just a matter of sending them over?

Neither svnsync nor svnadmin dump/load will take care of things like hook scripts/configuration files. You will have to copy these over manually and place them in their appropriate paths.
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?

While svnsync'ing you don't need to worry about authz at all, because I see that the document you posted suggests init over file:// . This will not involve authz. You will however need to set up and configure authentication and authorization just like it is in the old system when you want to start using the new system.

Regards,
Arwin
Received on 2017-07-28 08:37:53 CEST