subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: how do I revert a bad commit without creating a new revision?
Date Fri, 08 Jul 2011 07:16:24 GMT
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)

Mime
View raw message