subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "CopySvnsyncMirrorToMaster" by JulianFoad
Date Tue, 02 Apr 2013 15:51:33 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "CopySvnsyncMirrorToMaster" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/CopySvnsyncMirrorToMaster?action=diff&rev1=9&rev2=10

Comment:
Add a cautionary note

  
  == The Repair ==
   1. Create a new repository that will become the new master.
-  2. Use 'svnsync init' to setup the slave as the temporary source for the new master.
+  1. Use 'svnsync init' to setup the slave as the temporary source for the new master.
-  3. At this point 'svnsync synchronize' can be used to bring the new master up-to-date,
but rsync is probably faster.
+  1. At this point 'svnsync synchronize' can be used to bring the new master up-to-date,
but rsync is probably faster.
    * rsync 'db/current'
    * rsync 'db' excluding 'db/current', db/locks', 'db/transactions', 'db/txn-protorevs',
'db/revprops' and 'db/rep-cache.db'
    * make slave read-only
    * rsync 'db/rep-cache.db'
    * make slave read-write
+   {{{#!wiki caution
+   [JAF] Syncing the rep-cache at this point doesn't seem entirely safe.  It now contains
rep data for any revisions committed to the slave after 'db/current' was sync'd.  Could this
potentially break the commits of those revisions to the new master, which 'svnsync' will perform
in step 4?  Depends partly on whether we have defensive coding in place for the case where
we find a rep cache entry pointing to a revision greater than the last committed revision.
+   }}}
-  4. Adjust svn:sync-last-merged-rev to the youngest revision in the new master and run 'svnsync
sync'.
+  1. Adjust svn:sync-last-merged-rev to the youngest revision in the new master and run 'svnsync
sync'.
-  5. Disable revprop changes on the master, or make the master read-only.
+  1. Disable revprop changes on the master, or make the master read-only.
-  6. Copy 'db/revprops' from the master into the new master excluding db/revprops/0/0.
+  1. Copy 'db/revprops' from the master into the new master excluding db/revprops/0/0.
-  7. Make the master read-only if not already.
+  1. Make the master read-only if not already.
-  8. Ensure slave is up-to-date and run 'svnsync sync' to get any final commits.
+  1. Ensure slave is up-to-date and run 'svnsync sync' to get any final commits.
-  9. Copy 'db/revprops/0/0' from the master to the new master (removing svn:sync- revprops).
+  1. Copy 'db/revprops/0/0' from the master to the new master (removing svn:sync- revprops).
-  10. Take master offline.
+  1. Take master offline.
-  11. Replace master 'db' with 'db' from new master.
+  1. Replace master 'db' with 'db' from new master.
-  12. Check whether 'db/fsfs.conf' needs to be adjusted.
+  1. Check whether 'db/fsfs.conf' needs to be adjusted.
-  13. Bring master back online.
+  1. Bring master back online.
  

Mime
View raw message