subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <>
Subject Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance
Date Sat, 29 Jul 2017 09:39:30 GMT
On Sat, Jul 29, 2017 at 1:16 AM, James H. H. Lampert
<> wrote:
> On 7/27/17, 11:15 PM, Ryan Schmidt wrote:
>> 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.
> . . .
>> 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.
> . . .
> and Arwin and Nico said similar things.
> Thanks, Ryan, Arwin, and Nico.
> It took a bit of futzing around, but as I type this, I'm replicating a
> repository (the smallest and currently least-active one).
> It took me a while to realize that the hooks with .tmpl extensions were
> templates, not live hooks, and I was right on the verge of asking for help
> when I looked at the instructions again, and realized that instead of
> setting up the required null hook, I'd overwritten a template (DUH!)

Indeed, you only need to copy the files under $REPOS/hooks which are
not ending in .tmpl :-). And for the custom hook scripts you have:
maybe review them and compare the comments section at the beginning
with the new corresonding template to see if there are new features
(perhaps copy over the new comment block to your custom hook script).

Two other things which are also not transferred by svnsync (nor by dump/load):
- config files (under $REPOS/conf), for instance authz
- locks (server-side locks, of the svn:needs-lock type): these should
be copied from $OLDREPOS/db/locks to $NEWREPOS/db/locks

FWIW, I've documented some of these things in an extended answer in
our FAQ, about dump/load (some of these things also apply to svnsync):

For the record, you can also perform an incemental dump/load with
minimal downtime (I explained this procedure in the FAQ). But svnsync
is still a lot easier, because of the automatic normalization of
properties (which is not done automatically by 'svnadmin load' at the
moment, which will error out on non-LF line endings in svn:log
messages and things like that, possibly giving a lot of headaches ...
see FAQ).


View raw message