On Fri, 08 Jul 2011, Daniel Shahaf wrote:
You missed a step.
Without that step the procedure will result in corruption (data loss) at
an undetermined time in the future.
The last time I performed this sort of repository truncation
was with a fsfs repository format 5, db/format 3, without a
rep-cache.db (as created by svn version 1.5). I don't know what
else you have to do if you have db/format 4 with a rep-cache.db
(as created by svn version 1.6), but I imagine it's something like
using the sqlite3 command line client to "delete from rep_cache
where revision > ${last_good_revision};". Newer formats will
probably need different treatment. Again, this is all unsupported
and at your own risk.
--apb (Alan Barrett)
[original message repeated for reference:]
To truncate a repository that uses the "fsfs" format, so that you
lose everything after a certain revision, you can try the following
procedure. This is not supported, and might break everything.
1. Ensure that no new changes can be committed. (Tell your
users to stop work, or rename the directory on the server to
make it inaccessible, or activate some hook scripts that deny
permission for any changes.)
2. Ensure that you have a backup.
3. Examine the "db/current" file in the repository. It should
contain the most recent revision number. If it's not what
you expected, then give up.
4. Change the "db/current" file, making it refer to the most
recent "good" revision (e.g. 417810) instead of to the newer
revisions that you want to disappear (e.g. 417811).
5. Delete the db/revs and db/revprops files corresponding to the
revisions that you want to disappear (e.g. db/revs/417/417811
and db/revprops/417/417811).
6. Allow access to the repository again.
Any working copies that have references to the revisions that have
disappeared, will now be broken. You may be able to fix them via
"svn update -r${LAST_GOOD_REVISION}", but in the worst case, your
users will have to delete the working copies and check them out
again.
--apb (Alan Barrett)
