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

[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








reply via email to

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