[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: cannot seal a version
From: |
David Allouche |
Subject: |
Re: [Gnu-arch-users] Re: cannot seal a version |
Date: |
Mon, 02 May 2005 17:54:28 +0200 |
On Fri, 2005-04-22 at 23:53 +0200, martin f krafft wrote:
> wing:~/debian/zope/packages> baz commit --seal -s 'sealing 0.9.6-1'
> [... a lot of output ...]
> arch_commit: unable to acquire revision lock (internal error in
> archive-pfs.c(pfs_lock_revision))
> tree: /home/madduck/debian/zope/packages
> revision: address@hidden/debian-dir--zope-testcase--0.9.6.1--version-0
>
> So I try to unlock it:
>
> wing:~/debian/zope/packages> baz lock-revision -b
> address@hidden/debian-dir--zope-testcase--0.9.6.1--version-0
> lock-revision: unkown lock state for
> address@hidden/address@hidden/debian-dir--zope-testcase--0.9.6.1--version-0
> (lock was in transition -- consider retrying)
>
> So what now?
What is the output of
tree -F
address@hidden/
in the archive?
There appears to be a flaw in the locking, users report this kind of
problem from time to time, often they have been removing lock dirs in
the archive by hand, but sometimes not. It would be nice if somebody
could isolate the problem.
Generally, fixing the problem involves:
1. making sure there are no ++revision-lock directory in any
revision of the version
2. copying the ++revision-lock from the latest revision of a
version which is known good and not undergoing a commit (or
recreating the lock by hand, but I consider copying to be
cleaner).
--
-- ddaa
signature.asc
Description: This is a digitally signed message part
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Gnu-arch-users] Re: cannot seal a version,
David Allouche <=