### NOT READY! This page is currently being written and is not yet finished so do not use it.

How to repair a damaged master repository by copying data back from an svnsync mirror repository that is complete and in good working order.

The Scenario

FSFS repository, svnsync mirror, used in a write-through proxy configuration.

Both the master and the mirror repository are the same repository format.

The master repository has corruption in some of its revision files, but the mirror repository does not. (Issue 3845).

Master and slave are still live since commits that don't access the corrupt data still work. We want to copy the slave to the master with minimal downtime.

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.
3. 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

     [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'.
5. 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.
7. Make the master read-only if not already.
8. 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).
10. Take master offline.
11. Replace master 'db' with 'db' from new master.
12. Check whether 'db/fsfs.conf' needs to be adjusted.
13. Bring master back online.