Re: Breaking svnsync mirrors
On Fri, Sep 6, 2019 at 1:53 PM Branko Čibej 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
Re: Breaking svnsync mirrors
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. -- Brane
Breaking svnsync mirrors
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? Thanks, Dg. -- David Grierson - Lead Engineer Sky - UK Information Systems - Tools Team Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
