[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: how do I revert a bad commit without creating a new revision?

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 8 Jul 2011 20:35:55 +0300

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)



> [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)
Received on 2011-07-08 19:36:48 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.