Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 8 Jul 2011 20:35:55 +0300
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Alan Barrett <apb@cequrux.com>
Cc: users@subversion.apache.org
Subject: Re: how do I revert a bad commit without creating a new revision?
Message-ID: <20110708173555.GA13328@daniel3.local>
References: 
 <CAEw_t55tw=TProYN6iU8QCJ6K7UFKnXiRbsuPmP5K2=Z8NJsLw@mail.gmail.com>
 <CABzHfV=Syk9=dumuTPJKKrf3KXn8JH2ZUfHzfyMJk_C-ynPmhw@mail.gmail.com>
 <20110708064724.GA821@apb-laptoy.apb.alt.za>
 <20110708071623.GA10031@daniel3.local>
 <20110708084410.GA1620@apb-laptoy.apb.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110708084410.GA1620@apb-laptoy.apb.alt.za>
User-Agent: Mutt/1.5.20 (2009-06-14)

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)