...
- 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
Note [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.
- 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.