Daniel Shahaf <d...@daniel.shahaf.name> writes: >> The official way of doing this is to dump the repository from r0 >> to rN (using svnadmin dump) and loading this dump file into a freshly >> created repository (svnadmin load). >> Since you're creating an svnsync mirror you should probably run >> 'svnsync init' before loading the dump file, and after loading adjust >> the svn:sync-last-merged-rev revision property on r0 to say 'rN'. >> > > Need to truncate rep-cache.db Stefan! (otherwise the invariant on it > won't hold, which can cause lossy corruption) > > sqlite3 'delete from rep_cache if revision > N' rep-cache.db
No need to do that if dump/loading. >> There is a shortcut if you want to avoid the dump/load cycle, but it >> involves messing with data in the repository so please don't try this >> at home and make backups first! Set the file 'db/current' to rN and >> remove all files in db/revs and db/revprops between HEAD and rN. >> Then run 'svnadmin recover', reset svn:sync-last-merged-rev to rN and >> hope that everything still works. Better try this on a small test >> repository first! Truncating the rep-cache is necessary if you backdate db/current. Running 'svnadmin recover' will do it for you if you use 1.7 but not if you use 1.6. For 1.6 use the sqlite3 command or simply delete db/rep-cache.db. The other thing that can go wrong if you truncate a repository is that you may end up with orphan exclusive locks (locks on files that don't exist). This will prevent you adding those files in future until you unlock the path. This is unlikely to affect an svnsync mirror since you probably don't lock files in the mirror. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
