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.