gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] revision lock problems (with


From: Miles Bader
Subject: Re: [Gnu-arch-users] revision lock problems (with
Date: Mon, 29 Dec 2003 18:51:14 -0500
User-agent: Mutt/1.3.28i

On Mon, Dec 29, 2003 at 08:57:18AM -0800, Tom Lord wrote:
> How did that happen?  Did you break a lock in that revision "by hand"?

Yeah -- if tla commit fails because it sees the archive is signed, but can't
find a way to sign it, it leaves the locks state messed up, with this error
message:

   ********************************
   SIGNATURE DEMANDED FOR ARCHIVE
     address@hidden
   BUT NO RULE PROVIDED

   Consider creating ~/.arch-params/signing/address@hidden
    or ~/.arch-params/signing/=default

   ********************************



   (You may also have to use tla lock-revision -b before
    retrying this transaction.  See tla lock-revision -H)


   unable to complete transaction due to signature failure

However I couldn't get `tla lock-revision -b' to do anything sensible:

   $ tla lock-revision -b tla-tools--devo--0--patch-2
   lock-revision: revision not locked --
   address@hidden/tla-tools--devo--0--patch-2

   $ tla lock-revision -b tla-tools--devo--0--patch-1
   lock-revision: revision not locked --
   address@hidden/tla-tools--devo--0--patch-1

   $ tla lock-revision -u tla-tools--devo--0--patch-1
   lock-revision: error unlocking revision
   address@hidden/tla-tools--devo--0--patch-1 -- lock not held

No doubt this is due to operator error in some way but at least I think the
error message (and/or the help for lock-revision) should be a bit more clear
about exactly how you're supposed to do it; well ideally of course, commit
shouldn't leave the revision locked in this circumstance!

Anyway, I couldn't figure out how to break the lock properly, so I did
manually by moving the lock directory, in a way that always seemed to work in
the past.  I tried to make sure the result was correct by looking at the
corresponding lock directory in an un-messed-up branch/revision in the same
archive, and as far as I could see the contents/permissions were the same ...
but I supposed I must have missed something.

So what exactly _is_ the lock directory supposed to look like now?  From
your response I gather that something is obviously wrong ...

Thanks,

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]