Sharing a repository file system

[Matt Mackall]

On Tue, 2010-06-29 at 21:38 +0100, Craig Box wrote:
> Hi,
> 
> I am looking at moving a Mercurial repository into Amazon EC2, and
> want to have it available for publishing with Apache/mod_wsgi on
> machines across two availability zones. As this is a WAN situation
> (AZs are in different data centres) regular cluster file systems like
> GlusterFS don't perform great here.

Here's how the locking works:

First, there is no read-side locking at all. Any number of readers can
be reading at any time and don't do anything to signal that they are
active. They just read.

There is a single write lock and there can be a single writer at a time.
The lock is implemented as a file that's atomically created. Any shared
filesystem that has atomic file creation should work. On systems where
symlinks are allowed, the lock is a symlink which stashes the lock
metadata in the link itself atomically on creation.

Consistency is managed by ordered appends: filelogs first, then
manifest, then the changelog. Because the changelog is written last,
changesets and their contents are effectively invisible to other readers
until commits are finalized.

----

So: just about any distributed filesystem with conventional semantics
will do just fine. The only contended resource is the lock file. As
there is only ever one writer in a repo, even fairly naive locking
managers should have no problem. And the read side should obviously
scale very nicely.

rsync-like approaches can work, but are less efficient. And you also
have to ensure that the ordering rules (ie 00changelog.i last) are
preserved, which can be tricky. 

> Is it possible to use something like inosync or csync2 to rsync a
> Mercurial repository between servers when it is changed?  Can we have
> a commit action on server 1 be to do a push to server 2?  Is DRBD a
> suitable option?  Is there a better way?

A cluster filesystem built on DRBD should work, yes.

-- 
Mathematics is the supreme nostalgia of our time.