You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by michael mac <mi...@gmail.com> on 2011/07/08 02:42:29 UTC
how do I revert a bad commit without creating a new revision?
Hi,
During my svnsnyc process to mirror a repository I received the following
error "Problem replaying revision [500, #190004]" I was able to track down
the revision in question which is 417811. After talking to the developer
that made the commit I found there was a problem with one of the filename
syntax which used character '0x1' in one of the file.
My question, it there a way to revert revision 417811 to previous 417810
without commit a new revision? I've looked at svn merge and svn revert and
both require I new commit revision. My goal is continue to use svnsync to
mirror the repository and in order to do that I need to get past r417811. I
have confirmed this revision can be dropped altogether.
My last option which I can think of is the use svnadmin dump and load,
excluding r417811 and then adding it as a dummy revision, but I'm trying to
avoid this as it takes much more time and effort.
Thanks,
Michael
Re: how do I revert a bad commit without creating a new revision?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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)
Re: how do I revert a bad commit without creating a new revision?
Posted by Alan Barrett <ap...@cequrux.com>.
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};". Newer formats will
probably need different treatment. Again, this is all unsupported
and at your own risk.
--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)
Re: how do I revert a bad commit without creating a new revision?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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)
Re: how do I revert a bad commit without creating a new revision?
Posted by Alan Barrett <ap...@cequrux.com>.
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)
Re: how do I revert a bad commit without creating a new revision?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/7/8 michael mac <mi...@gmail.com>:
> Hi,
>
> During my svnsnyc process to mirror a repository I received the following
> error "Problem replaying revision [500, #190004]" I was able to track down
> the revision in question which is 417811. After talking to the developer
> that made the commit I found there was a problem with one of the filename
> syntax which used character '0x1' in one of the file.
>
Maybe you can
1) dump this revision alone,
2) edit its dump file: change the file name to something usable
3) load this revision into slave repository
4) run svnsync with revisions up to HEAD
5) delete the file from master repository
6) repeat the trick from steps 1)-3) to delete the "good" copy of this
file from slave
and so moth will be reasonably in sync.
Now you can replace master with a copy of slave.
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).
You have 0.5 million revisions at stake. I do not know how long
recover will run. How long svnadmin verify runs with such a
repository? What will happen with representation sharing DB (will it
recover from extra data as well, or it has to be deleted manually)?
>
> My question, it there a way to revert revision 417811 to previous 417810
> without commit a new revision?
No. It is not possible.
(keyword: obliteration)
> I've looked at svn merge and svn revert and
> both require I new commit revision. My goal is continue to use svnsync to
> mirror the repository and in order to do that I need to get past r417811. I
> have confirmed this revision can be dropped altogether.
>
> My last option which I can think of is the use svnadmin dump and load,
> excluding r417811 and then adding it as a dummy revision, but I'm trying to
> avoid this as it takes much more time and effort.
You have slave that is at r417810 now. So you do not need to load
revisions up to 417810 -- you can start with what slave already has.
Best regards,
Konstantin Kolinko