On Fri, Sep 6, 2019 at 1:53 PM Branko Čibej <brane_at_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
Received on 2019-09-06 14:40:36 CEST