[e-lang] Revision control for E

[Nathaniel Smith]

<zooko at ...> writes:
>  MarcS wrote:
> >
> > If Monotone uses certificates in any fashion remotely similar to the 
> > traditional way certificates are used to make life difficult, let us 
> > please reject it immediately.

Please, we _would_ like to be able to look ourselves in the mirror in
the morning ;-).

Seriously, I don't know if monotone is right for you guys, but I do
think that y'all of all people might be interested in taking a look at
it in particular.

> I'm not sure if you would regard Monotone's access control system as
> rejectionable.  It probably deserves study as a novel and actually-deployed-
> and-used decentralized access control regime.  I suspect that Monotone may have
> drawn inspiration from OpenCM.

I'm not sure how much came from OpenCM directly.  My impression from
reading the OpenCM papers was definitely that monotone was the natural
successor.  Others may or may not agree.

But, you'll probably find monotone's _current_ access control system
objectionable in any case.  It is not really a Real Solution at the moment
-- just the initial good-enough-to-limp-along hack that we stuck in to
have something usable while we finished off the basic versioning backend.
Then, the plan was, we could get back to the interesting workflow and
trust parts!

It turns out "basic versioning" is a sort of non-trivial, but, umm...
three years and a giant whack of new "boring" theory later, we _are_
almost ready to get back to the fun stuff :-).  I was actually planning
to send a call for comments over towards this community at some point in
the next few months, since the eventual goal is a more SPKI/petnames-ish
system, though there are some interesting (IMO) issues around usability
and the particular problem context.  We have some sketches on how all
this might work out.

The very very short version (I sort of have a master's thesis to write
this week :-)) is that there are basically two branch/permission models
for VCSes:
  Model A: a branch is a particular set of bits in a particular place
    on a particular hard drive.  Copying those bits somewhere else
    creates a new branch.  The person who owns the hard drive grants
    permission to modify the branch, by granting permission to modify
    the files on the hard drive.  (Possibly with some well-formedness
    checking, e.g. in some configurations it is not possible to remove
    old versions, only create new ones.  The point is that mutating a
    branch is equivalent to mutating an owned storage medium.)
    This model is used by every VCS except monotone.
  Model B: there are versions, content-identified, that may be copied
    freely.  Any particular repo is simply a bag of facts, recording
    the existence of different commits; the network protocol can
    promiscuously spread these facts, and this copying has no semantics.
    Each user determines for themself, locally, which revisions they
    would like to consider to belong to any particular branch (though
    they may delegate the particulars of this decision to others), on
    the basis of crypto-fu distributed along with the revisions.
    This model is used by monotone.

Model B is interesting in that it allows "truly shared branches"; in
most systems, if you want to disconnect, you have to create a new branch
(or even, a new branch is created for each and every checkout).  In this
model, branches are used only to indicate project goals.  It also has all
sorts of interesting follow-on effects, like allowing the promiscuous
copying (_great_ for robustness and usability); probably we haven't even
discovered all of these yet.

Of course, the problem with Model B is that it's tricky to get really
right, especially the delegation part :-).  That's what we're just
starting to ramp up work on.  Anyone interested in the particulars of
what we do _now_ can probably glean them from the manual:
  http://venge.net/monotone/docs/index.html
And anyone interested in what we're thinking about what to change, hmm,
there's a wiki page with some info:
  http://venge.net/monotone/wiki/VersionedPolicy
though a lot is just in our heads.


One more note (sorry, Zooko, but someone has to mention this): I have some
concerns about recommending darcs to any sort of largish project... simply
because for right now, they have some deep problems with their algorithms
for merging (and in darcs, everything is merging).  AFAICT, it is
reasonably common that repositories simply become wedged, and elaborate
workarounds, including the hunting down the deletion of particular commits
from every extant checkout, are required.  Furthermore, this isn't some
trivial implementation bug, but a theoretical issue with the algorithms;
there may or may not be a solution, no-one knows (though they are
hopeful).  They've been working on solving it for more than a year now,
but have not done so yet.

I really hope they _do_ solve it, darcs has some really neat stuff in it,
and is otherwise a really worthy opponent :-) -- and people definitely do
manage to get stuff done despite this.  But it seems irresponsible to not
at least mention the issue, so it can be considered during discussion.
Zooko's probably much more qualified than I to talk about what exactly the
implications are.

Cheers,
-- Nathaniel