File LOCK methods

David Dyer-Bennet dd-b at dd-b.net
Wed May 19 15:06:14 UTC 2010


On Tue, May 18, 2010 18:15, Mads Kiilerich wrote:
> David Dyer-Bennet wrote, On 05/18/2010 05:22 PM:

>> I don't think controlling the LOCK file through hg and coordinating via
>> the central repository can work, though.  It's not possible to update
>> just
>> the LOCK file independent of any other file, in either direction; a push
>> or a pull can always bring or send extra stuff, whatever else happens to
>> have been changed.

> /me is thinking loud:

Thanks!  Several good ideas, and kicking the general problem around always
helps me clarify my thinking.  I'm new to Mercurial, so I'm always a
little worried I'm missing something, or heading down a blind alley.

> A lock system obviously need some kind of transport mechanism. Mercurial
> already have a working transport mechanism, and (ab)using that solves
> one of the challenges. Using the existing repository do however not seem
> like a good solution - using a separate repository might be a better
> solution.

A separate repository is an interesting idea there.  A related suggestion
was to just put the file that needs locking in a Subversion
sub-repository, which also sounds like it might work.

I hacked together the beginnings of a web-based lock manager (using
transactions in an SQLite db for atomicity) yesterday, I'm thinking I
could access that from suitable hook scripts.

Which sounds like we have three workable solutions floating around our
heads; that can't be bad.

> Perhaps:
>
> Repositories needing locks could have a .lockrepo containing the
> url/path of a central lock repository.
>
> Client hooks could clone that repository to .hg/locks/ or pull and
> update it.
>
> A command (standalone or as a Mercurial extension) could lock a file by
> pulling and updating the locks repository, creating a file with the same
> name as the file below the locks repository and write the username to
> it, adding and committing it and pushing the locks repository.

One problem is that hooks have to be manually installed in each client
environment, they don't propagate.  While I understand the security
implications, and would probably have made the same decision, this
drastically limits the usability of hooks for anything mission-critical at
the client side (they're still fine for central enforcement).

> Depending on how advisory you want the locks to be you could let an
> update hook make all tracked files in the working directory read-only,
> unless the locks repo shows that the user has locked the file. Locking a
> file should also make the working directory file writable
>
> A precommit hook could check that no un-locked files are committed
> locally (and perhaps be kind and try to aquire the lock).
>
> A server-side hook could check that no locked files are pushed by the
> wrong users.
>
> Locks could be removed again by a client-side outgoing hook - or by a
> server-side hook.

Yes, I was thinking of those.  I'd like to prevent accidents, but let
people deliberately edit in parallel.  But I'd like to make sure that the
one who locked doesn't get forced to merge changes by somebody committing
first; that can be done as a central hook.

>> Are extensions a lot more powerful than hooks?  Can they solve this
>> problem?
>>
>
> Yes and no. Hooks can hook in at specific points while extensions can
> hook in everywhere and do anything. That do however not solve the
> problem, and it seems like the problem could be solved just with hooks.
> An extension might however give a "better" solution by many metrics
> (simplicity, portability, stability, etc).

Simplicity as in ease of installation, right?  That might be the deciding
factor.

Or people may just decide to go with TFS instead of Mercurial; that's
probably actually the simplest choice (and it looks to me as if it's as
good as subversion, maybe a bit better in some areas, so it would actually
be a big improvement over VSS).

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info




More information about the Mercurial mailing list