You missed a step.
Without that step the procedure will result in corruption (data loss) at
an undetermined time in the future.
Alan Barrett wrote on Fri, Jul 08, 2011 at 08:47:24 +0200:
> On Fri, 08 Jul 2011, Konstantin Kolinko wrote:
> >Another possibility: I think it is possible to effectively
> >truncate the repository by removing some files + running svnadmin
> >recover. Just theory - I have not tried it. I wish there were
> >official command (or instruction) how to truncate a repository (as
> >a cheap alternative to implementing obliteration).
>
> 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)
