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 17:35:55 GMT
Alan Barrett wrote on Fri, Jul 08, 2011 at 10:44:10 +0200:
> 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};".

Correct.  Either run the SQL command you cite or rm rep-cache.db.

(And in either case one needs to verify that no txns currently in-flight
have already caught the rep-cache reference before it was removed from
the DB; I don't remember offhand at what point in the txn that happens.)

> Newer formats will probably need different
> treatment.  Again, this is all unsupported and at your own risk.
> 

True.  And thanks again for including these unequivocal "Unsupported
/ At your own risk" warnings very clearly. :-)

> --apb (Alan Barrett)
> 

Best,

Daniel

> [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)

Mime
View raw message