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

Re: [BUG] Removal of dead transactions can fail

From: Jan-H. Jagla <jhjagla_at_gams.com>
Date: 2007-07-02 10:46:34 CEST


Thanks for the reply! I'm going with manually deleting since dumping and
loading the repo, takes some time, in which it has to be ensured that
nobody tries to connect to the repo and also doesn't maintains locks (I


Jonathan Ashley wrote:
> Hi, sorry for the delay replying; I've been out of the office.
> I did delete the transactions manually, though I made sure I was
> fully backed up first, and kept a copy of the deleted files. I
> didn't get any problems at all. Also subsequently ran an svnadmin
> verify on the repository, and another verification script from
> http://www.szakmeister.net/blog/?page_id=16 on the suspect revisions.
> I'm still with SVN 1.4.3; my environment makes it a fairly major
> job to do an update, but now with Apache 2.2.4.
> regards,
> --
> Jon Ashley
>> -----Original Message-----
>> From: Jan-H. Jagla [mailto:jhjagla@gams.com]
>> Sent: 27 June 2007 10:03
>> To: Jonathan Ashley; users@subversion.tigris.org
>> Subject: RE: [BUG] Removal of dead transactions can fail
>> Jon,
>> exactly the same occurred to me with subversion 1.4.3 now
>> updated to subversion 1.4.4.
>> There are a few transaction which cannot be removed using
>> rmtxns since the they are a 'Reference to non-existent node
>> ...". The directories ..\db\transactions\651-1.txn exist but
>> only contain an empty props file.
>> svnadmin recover and verify say that all is fine
>> Did you try deleting them manually? Did this work or did you
>> experience any problems? Or is there another workaround?
>> Thanks
>> Jan
>> -----------------------------------------------------
>> Hello,
>> I have hit a problem which seems to have been around a few years:
>> This morning, I got a call from a user who couldn't commit,
>> getting an error "couldn't unlock unknown transaction", with
>> a reported transaction id of 37404-1.
>> I tried a dead transaction cleanup. All except the
>> troublesome transaction were removed, but the remaining
>> removal failed with the error message "svnadmin: Reference to
>> non-existent node '0.0.t37404-1'
>> in filesystem 'imp/db'". ('imp' is the name of the repository.)
>> Yikes! Anyway, I ran an 'svnadmin verify', which reported no
>> problems, so I think it's probably just the transaction
>> that's corrupted. I'd assume that 'verify' would check that
>> nodes were present where they were supposed to be. Also, I
>> checked the file that went in to revision 37404 and it's
>> exactly as it should be. Looking at the contents of the
>> transaction itself, it's pretty clear that it relates to the
>> failed commit (which is nothing to do with revision 37404; I
>> suspect another user committed that shortly after the
>> problematic commit failure).
>> This was reported in December 2004 and issue 2160 was raised
>> as a result, see http://svn.haxx.se/dev/archive-2004-12/0429.shtml
>> That issue is marked as resolved, but maybe it isn't really?
>> Does anyone agree that I should raise this as a new issue?
>> Also, can I still safely remove the transaction manually from
>> db/transactions using 'rm -rf'? I'm going to have to anyway,
>> but I would like some reassurance :-)
>> I'm using SVN 1.4.3 on Windows 2003, Apache 2.0.55.
>> regards,
>> --
>> Jon Ashley
>> > -----Original Message-----
>> > From: oleksa borodie [mailto:oleksa.borodie@gmail.com] >
>> Sent: 22 March 2005 09:11 > To: users@subversion.tigris.org
>>> Subject: Re: Commit failed: parent is not under source >
>> control but child is > > Hello > It seems that connection
>> was broken after data was > transferred to the server and
>> before local .svn files were > updated. If I make checkout
>> from repositiry than all seems > fine :-0 I've made some
>> tests and observed that if > connection is broken at the
>> commit time and I got unremovable :( txn :
>> >
>> > svnadmin rmtxns e:\subversion 187-1
>> > svn: Reference to non-existent node '0.0.t187-1' in >
>> filesystem 'e:/subversion/db > > as described at >
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2160
>> > When this fix will be available in binary packages? With 1.2?
> This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis.
> Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support@praxis-his.com.
> Praxis High Integrity Systems Ltd:
> Company Number: 3302507, registered in England and Wales
> Registered Address: 20 Manvers Street, Bath. BA1 1PX
> VAT Registered in Great Britain: 682635707
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

Jan-H. Jagla                        mailto:jhjagla@gams.com
GAMS Development Corporation             GAMS Software GmbH
1217 Potomac St. NW,                   Eupener Str. 135-137
Washington DC, 20007, USA            50933 Cologne, Germany
Fon/Fax: +1 202 342-0180/1      Fon/Fax: +49 221 949-9170/1
http://www.gams.com                      http://www.gams.de
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 2 10:46:38 2007

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.