[tahoe-dev] hglafs v0.1 - An hg extension for Tahoe-LAFS repositories.

[Nathan]

= Announcing hglafs version 0.1 =

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


= Related Work =

Mercurial is a distributed revision control system:
http://selenic.com/mercurial

Tahoe-LAFS is a distributed, secure, file-system:
http://allmydata.org/


= Getting the Code =

If you are stuck on the boring old web2.0, you can access this and future
releases from bitbucket:

http://bitbucket.org/nejucomo/hglafs


If you are part of the Tahoe-LAFS Cool Kids' Club^H^H^H^H Volunteer Grid,
you can access this and future releases of the hglafs extension with
this capability:

URI:DIR2-RO:76muboby62wixn3m7x7cudrxme:japh4d6w27syvhd2vi7tddftk55u45gocv77iodwo53cv67ntqbq

Browse to the "./tip/contents" directory to get the latest revision's
contents.  Browse through "parents" links to travel back in history.
Presently the only way to find a release tag is by examining the "tags"
file in each revision's directories.  [FIXME: Add tag links.]


= Installing and Using the extension =

The repository contents includes a README.txt for configuration and
use instructions.


= Use Cases =

"Why would I want to use Tahoe-LAFS for repository storage?"

Doing so provides some advantages of a centralized repository while
preserving features of decentralized development.

For example, the developers need not be solely responsible for providing
a high-availability central repository (such as via "hg serve") then
configuring access to it, nor must they rely on a 3rd party for privacy
and/or availability (eg: bitbucket.org can read and nuke your repository).

Tahoe-LAFS repositories provide privacy, fine-grained access control,
and high availability.  This is true even in the face of an adversary
who controls many of the storage hosts, and whose goal is denial of
service or privacy violation!

Fine grained access control allows sharing read/write, read-only with
future updates, immutable changesets with complete history, or immutable
changeset contents with no history.

A given changeset need only be stored once for any number of forks,
even when the owners of forked repositories do not otherwise cooperate.
(Note: This feature requires convergent encryption, a feature which
lacks a nice intro on the tahoe-lafs.org wiki.)


= Roadmap =

The holy grail for this extension is to provide a new repository scheme,
such as "lafs://" which works transparently with all hg commands (such
as clone, push, and pull).

I have begun investigating this approach in a fork.  Let me know if
you're interested in contributing.


= Contributing =

Please discuss development for this extension through the tahoe-dev
mailing list or irc channel.  You can find those here:

http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev

Development tracking for this extension will rely on bitbucket.org.
(So much for my earlier smugness.  ;-)



Have a nice day!

Nathan Wilcox aka nejucomo