Message-ID: <BAY20-F23B6858A16A6D58B2277368E7D0@phx.gbl>
In-Reply-To: <41FFA6EF.4080704@arbash-meinel.com>
From: "Rjae Easton" <rjae_easton@hotmail.com>
To: john@arbash-meinel.com
Subject: Re: [Gnu-arch-users] How to recover from interrupted commit...
Date: Tue, 01 Feb 2005 11:55:09 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Cc: gnu-arch-users@gnu.org
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 4386
Lines: 138
>From: John Arbash Meinel <john@arbash-meinel.com>
>To: Rjae Easton <rjae_easton@hotmail.com>
>CC: gnu-arch-users@gnu.org
>Subject: Re: [Gnu-arch-users] How to recover from interrupted commit...
>Date: Tue, 01 Feb 2005 09:57:35 -0600
>
>Rjae Easton wrote:
>
>>As my first post to the list - please permit a quick
>>this-is-a-phenomenal-product (so you know where I stand). Now I
>>suspect we're all very busy so I will be succinct...
>>
>>This morning a commit was interrupted. I do not know how to properly
>>and completely recover from this failed commit. Based on the details
>>below can someone recommend - or point to a published HOWTO - the
>>standard steps one should take after such an event.
>>
>>[the details]
>>history: normal project operation over SFTP for 4 months (173 patches)
>>version: TLA 1.3
>>what happened:
>>$ cd archives/2004-DEV/research
>>$ nano -w `tla make-log`
>>$ nano -w ./build.properties
>>$ tla commit
>>(normal output e.g. stuff that's not source)
>>Password:
>>(some moments pass...then)
>>(a message regarding broken SFTP connection)
>>
>>...subsequently I receive the "unable to acquire revision lock" from
>>any user trying to commit changes to the project (using any
>>connection, SFTP or otherwise).
>>
>>The things I have tried:
>>1. removed ++revision... in root of project tree;
>>2. tla lock-revision -b...
>>3. tla lock-revision -u...
>>4. manually creating .../patch-174/++revision.../+content
>>
>>I am looking for a repeatable process as I can see this happening
>>randomly (chaos) in the future. I appreciate any effort you spend
>>helping me on this.
>>
>It should just be a matter of tla lock-revision -b with the correct
>patch-level.
>
>Is this a publicly available archive so that we can see what the current
>state is?

Unfortunately not.

>For me, when I try to commit to a hung archive I get:
>
>$ tla commit -s "nothing"
>
>You need a passphrase to unlock the secret key for
>user: "John A Meinel <john@arbash-meinel.com>"
>1024-bit DSA key, ID 848D0003, created 2004-02-24
>
>Enter passphrase:
>gpg: some signal caught ... exiting
>Killed by signal 2.
>
>[jameinel@Jigglypuff ~/dev/libzip]
>$ tla commit -s "nothing"
>arch_commit: unable to acquire revision lock (internal error in
>archive-pfs.c(pfs_lock_revision))
>    tree: /Users/jameinel/dev/libzip
>    revision: john@arbash-meinel.com--2005/libzip--dev-stdio--0.1--patch-4
>
>And just doing
>$ tla lock-revision -b
>john@arbash-meinel.com--2005/libzip--dev-stdio--0.1--patch-4
>
>With just a copy of the "revision:" line fixes the archive.

I am gathering that deleting the ++revision... directory unnecessary - and 
should be avoided. I am also getting the sense that during a commit, 
multiple patches may be locked. If this is true, perhaps the --break needs 
to be applied to each lock.

I did some investigation of the archive and noticed a list of "unlocked" 
patches - which leads me to think that multiple locks exist. But the message 
I get is consistent with what I see elsewhere: cannot acquire lock (on the 
latest patch). That patch dir unfortunately does not exist.

I guess I was hoping that a maintenance tool had been created that knew how 
to gracefully - and if necessary interactively - return to a pristine state. 
Do you or anyone else know of such a tool?

>You've done enough that I can't guarantee this will work, but it is the
>general solution.
>John
>=:->
>
>PS> My example would fail in baz, since if you exit the gpg signature,
>it automatically unlocks the revision. At least as of 1.1 or something
>like that. But since your case involves an ssh disconnect, I think it is
>still valid.
>
>>Thanks.
>>
>>--
>>Rjae Easton
>>Applanet, Inc.
>>c: +1.508.369.7339
>>e: reaston@applanet.com
>>blog: http://blogs.applanet.com/percs/
>>wiki: http://applanet.com/wiki/default.aspx/Rjae.HomePage
>>aim: M1ngSheng
>>msn: rjae_easton@hotmail.com
>>Y!: m1ngsheng
>>
>>
>>
>>
>>_______________________________________________
>>Gnu-arch-users mailing list
>>Gnu-arch-users@gnu.org
>>http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>>
>>GNU arch home page:
>>http://savannah.gnu.org/projects/gnu-arch/
>
>
><< signature.asc >>


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/