On Fri, Sep 6, 2019 at 1:53 PM Branko Čibej <br...@apache.org> wrote: > > On 06.09.2019 13:23, Grierson, David (Lead Engineer) wrote: > > Hi, > > > > We're in the process of migrating & upgrading our Subversion installation. > > In doing so we're encountering a handful of repos which were impacted by > > issue 4129 (https://subversion.apache.org/docs/issue4129). > > > > The fix for this (to dump & reload) has been successful with most of the > > repos, however to do this you need to have sufficient storage to duplicate > > the repos; and one of the repos in question is over 700GB in size! > > > > As an alternative, I'm looking to use svnsync to fix this repository; I'm > > just looking to clarify the process for completing this. > > > > On new host: > > 1) svnadmin create /path/to/new-repo > > 2) Create /path/to/new-repo/pre-revprop-change hook > > 3) svnsync init file:///path/to/new-repo https://url/to/old-repo > > 4) svnsync sync file:///path/to/new-repo > > > > Allow the data to copy across ... then ... > > 5) svnsync copy-revprops --skip-unchanged file:///path/to/new-repo > > > > At this point there will be a copy of the existing repository. Periodically > > we'll then be able to run the 'svnsync sync' and 'svnsync copy-revprops' to > > copy across any new revisions. > > > > We'll then schedule the cutover weekend so would perform something like: > > > > 1) Disable access to repos on old host. > > 2) Perform final 'svnsync sync ...' & 'svnsync copy-revprops ...' on new > > host. > > 3) Shutdown Subversion on old host. > > 4) Remove the following revision properties from revision 0 on > > /path/to/new-repo > > svn:sync-from-url > > svn:sync-from-uuid > > svn:sync-last-merged-rev > > svn:sync-lock > > > > I just want to confirm that my process seems sensible and that what I've > > described regarding breaking the svnsync mirror is correct. > > > > If anyone can see anything that I might have wrong or missed? > > Looks both sensible and correct to me, except that you seem to be > missing one step: > > 5) Copy httpd and/or svnserve configuration and hooks from the old host. > > You don't want to keep hooks for the synced repository in the production > repository. >
And locks from $oldrepo/db/locks to $newrepo/db/locks (this can take a couple of minutes ... lots of small files). Those are the "working copy locks" (people running 'svn lock $file', or their tool doing it for them), for which the server keeps the lock tokens. -- Johan
