[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] unable to acquire revision lock
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] unable to acquire revision lock |
Date: |
Mon, 17 Nov 2003 14:08:06 -0800 (PST) |
> From: Gurupartap Davis <address@hidden>
> How does the revision locking work, exactly? That is, what commands
> implicitly place a lock? When and how do they get removed?
Commands that add revisions (import, commit, tag) aquire (and then
release, normally) locks.
The lock-revision command can be used to aquire a persistent lock or
to release a lock you own or to break a lock someone else owns.
How they work is a bit tedious to explain. Abstractly, you can
regard a filesystem as a kind of "state machine" where transitions are
made by operations like `mkdir' or `rename'.
The semantics of those operations is really quite weak if you want to
work on, say, AFS or NFS -- it's just barely enough.
In general terms, the "+contents" directory is the same directory
(same inode) that usually becomes the next revision directory (e.g.,
patch-42).
If you consider interrupted commands, dropped net connections,
arbitrarily timed lock breaks and so on -- manipulating the
"+contents" directory is quite tricky. I believe that I've actually
mapped out all the achievable states (and that the arch commands
handle them) -- though I admit that my proof is scribbled on sheets of
printer paper stashed away in a closet somewhere rather than peer
reviewed.
What you did, by going and deleting the lock directory, was to
effectively "corrupt" the archive -- but in a way that is easy to
recover from by recreating the ++revision-lock/+contents directories
in the appropriate place.
So, why doesn't arch just automatically recreate those? Because it
can't without there being a highly unlikely but not impossible race
condition. Having to do it by hand is your punishment for not
finding the lock-revision command first :-)
-t