File LOCK methods

[Greg Ward]

On Tue, May 18, 2010 at 11:22 AM, David Dyer-Bennet <dd-b at dd-b.net> wrote:
> Then I was going to use a pre-commit hook to verify that they had the file
> locked before they could commit changes.  I'd write a standalone command
> to lock files when needed (and unlock).
>
> 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.

bfiles (my extension for handling large binary files) has a vaguely
similar problem: clients need to communicate with the central store
using the same underlying protocol as hg (SSH, HTTP) without
reinventing the world.  Since Mercurial does not (yet) have a nice way
for extensions to extend the wire protocol, we (well, really David
Douard did all the work) cobbled together an SSH protocol that is very
similar to Mercurial's own.  Conceptually this duplicates many ideas
from core hg, and unfortunately there is a bit of duplicate code too.
But it seems to work.

The latest code is here:
http://vc.gerg.ca/hg/hg-bfiles/file/tip/bfiles.py.  The code of
particular interest to you is the classes sshstore and sshstoreserver.
 In protocol terms, sshstore is the client and sshstoreserver is the
server.

> Are extensions a lot more powerful than hooks?  Can they solve this problem?

"Yes" and "Probably, but it's a fair amount of work".

Good luck!

Greg