Lock Extension

Centralized file-based locking.

{i} There are two extensions called lock: an older and smaller extension by Søren Mathiasen, and a newer and bigger extension by Martin Geisler. This page describes the the newer extension, see https://bitbucket.org/sorenmat/hglock/ for the other extension.

1. Status

This extension is not distributed with Mercurial.

Original Author: Martin Geisler

Current Maintainer: James Heard

Repository: https://bitbucket.org/jameslheard/hglock/

Issue tracker: https://bitbucket.org/jameslheard/hglock/issues

2. Introduction

Mercurial is not well suited for development that involves (binary) files that cannot be merged. One example is specification development using tools such as Framemaker or Word. Parallel versions of files occur naturally in Mercurial, so in trying to prevent this, we are "going against the grain". At the same time, introducing a different tool like Subversion is obviously not very attractive.

3. Lock workflow

The crucial thing is that users stay up to date with changes from others by pulling from the central team repository often and pushing as soon as modifications are done. The workflow looks like this:

As an exception, locks can be "stolen" or unlocks can be "forced" (e.g. someone went on holiday and left a file locked). Modifications to a previous revision are allowed as long as a separate named branch is used (e.g. to do a bug-fix release). If the team follows this workflow, (unintended) parallel versions will rarely occur --- only when a lock is stolen or unlock forced. The project can specify files for which locking is mandatory. Other files can also be locked.

4. Lock Extension

The proposed design for the lock extension follows.

4.1. Clarifications

4.2. Configuration

4.3. Commands

Note: Some commands can take multiple files as argument. The operation is not expected to be atomic (that is, 'hg lock', for example, can lock some files and fail to lock others). The command fails overall if the operation fails for an least one file. We ignore this complication in the description of the commands.

5. Scenarios

5.1. File forcibly unlocked

Scenario with mandatory locking is in effect for 'foo':

Solution: We must get foo back in the locked state and 'hg lock --force foo' does that. After that, the changesets can be pushed like normal.

The following diagram show the state changes:

As can be seen, the orange error state only has one exit: 'hg lock --force'.

6. Comparison with Subversion

Subversion has a similar feature where clients can lock files in the central repository. This extension is very similar with the following exceptions:

7. See Also

There is an older and smaller extension by Søren Mathiasen with the same name: https://bitbucket.org/sorenmat/hglock/.

There is a new locking extension by Steve Borho named simplelock. https://bitbucket.org/sborho/simplelock it is not as full-featured as hglock but it does not require any require server-side features, so it can be used with popular Mercurial web-hosting sites. It is also supported by TortoiseHg >= 3.7.1


LockExtension (last edited 2016-02-04 00:53:10 by SteveBorho)