Overview

About hglafs:

This prototype extension for the Mercurial revision control system allows
the user to create and publish to a repository stored in Tahoe-LAFS.

This is a *prototype* so set your expectations appropriately.  Currently
there's no support for pulling from a LAFS Repository.


References:

Mercurial: http://selenic.com/mercurial Tahoe-LAFS: http://allmydata.org/


Design Goals:

1. The LAFS-repository should be transparent, such that users can browse
revision contents and metadata without requiring this tool.

2. The hg interface should be as natural as possible.

3. Where it doesn't interfere with the above goals, hglafs should be
efficient.


HOWTO Contribute:

Join #tahoe-lafs on irc.freenode.net or join the mailing list.


HOWTO Play:

1. Make sure the hglafs directory (which contains a file called
__init__.py) is on the PYTHONPATH of hg.

2. Enable the extension in hgrc.  (I do this only for a specific test
repository until this tool becomes more stable.)

My hgrc contains:

[extensions]
hglafs =


You can also configure a custom lafs wapi URL:

[hglafs]
wapi = http://localhost:1234/


3. Create a lafs-repo:

$ hg lafs-create

This step will create the repository structure then modify your hgrc to
include this value:

[hglafs]
repocap = URI:DIR2:blah...
wapi = http://localhost:1234/


4. Push to the lafs repository:

$ hg lafs-push


5. Browse the repository structure through the wapi or other tahoe tools.
Improve hglafs.  Submit patches.  :-)


Implementation Notes:

The current ui does not meet goal 2.  A more natural interface would
be a new url type for mercurial repositories.  In addition there would
still be a command: hg lafs-create

The work flow would then be straight-forward for hg users:
$ cd my-proj
$ hg lafs-create
Created new lafs-repo: lafs://URI%3ADIR2%3Ablah...
$ hg push 'lafs://URI%3ADIR2%3Ablah...'

The user can hand out the readcap (or writecap provided the team
synchronizes writes).  Others can clone:

$ hg clone 'lafs://URI%3ADIR2-RO%3Ablah...'

And later pull changes:

$ hg pull 'lafs://URI%3ADIR2-RO%3Ablah...'

All of these commands can benefit from hg path aliases:

[paths]
default = ssh://blah...
lafs = lafs://URI%3ADIR2%3Ablah...

Now the user can do:
$ hg push lafs
$ hg pull lafs


Currently, retrieval (ie: lafs-pull) will be hard to implement.

Both this issue and the user interface issue may be solved by creating
the appropriate python interface to a lafs-repo and sticking it in
mercurial.hg.schemes as a monkey patch.