[Monotone-devel] Re: Monotone server

[Bruce Stephens]

Daniel Carrera <address@hidden> writes:

[...]

> Yeah, I was just reading up on those three (I already know Darcs and
> it doesn't use signatures). A lot of people say that Git is
> complicated and poorly documented, so I'm ignoring Git. Mercurial and
> Bzr both look easy to use, but like you say, they don't seem to have
> digital sigs, or the over-all security of Monotone.

I'm not convinced that such opinions of git are fair.

It's true that it's not a particularly cohesive design, but it's not
nearly as bad as it used to be (so I hear---I've only used versions
later than 1.5).  Underneath, the model really is cohesive, and is
(IMHO) just as simple as monotone's.  The issue is all the
higher-level commands that enough people thought useful, and those
commands don't always fit together very well (because nobody uses all
of them).

See <http://eagain.net/articles/git-for-computer-scientists/>,
<http://cworth.org/hgbook-git/tour/>,
<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html>,
<http://book.git-scm.com/>, for examples of good documentation of git
after 1.5.  Avoid documentation that mentions cogito, or seems more
than a couple of years old.  (The first link is different---that's
just the underlying DAG model which hasn't changed much.)

I think the three systems do offer signing, just not as pervasively as
monotone.  Ah, OK, bzr doesn't (yet) by the looks of it.  The other
two do:
<http://www.kernel.org/pub/software/scm/git/docs/git-tag.html>,
<http://www.selenic.com/mercurial/wiki/index.cgi/GpgExtension>.

In the git case you can sign (and verify) a tag object using gpg.
Such a tag will reference a revision, so transitively that gives you
assurance of the history.  (In that case it's not much different from
monotone; in monotone revisions aren't signed, rather the things
attached to revisions get signed, so if you have a tag, the only
signature that matters (arguably) is that one signature.)

>> Ease of use probably varies according to taste.  Viewed from a
>> distance they're all (disappointingly) equivalent, storing DAGs of
>> snapshots.
>
> DAG?

Directed acyclic graph.  (i.e., revisions typically have one or more
parents and one or more children, and that graph never has cycles.)
So different to darcs's set of patches model, and probably different
to AccuRev's streams model.  ("disappointingly" because it feels like
there ought to be other workable models, even if I don't have good
ideas of what they might be.  It's perhaps worth mentioning for the
n-th time that these systems tend to credit monotone for the basic DAG
model (where you hash the revision (including its parents) to get the
new hash, so you have a chain of hashes).)

>> They differ more in the details, and which details matter probably
>> varies.
>
> Yeah. Ex: Linus cares a lot about quickly merging large trees, Mozilla
> cares about decent performance on Win32 (so they chose Mercurial),
> etc. For me, desirable features include ease of use, security and
> being able to push changes to a live web host. Mercurial seems to have
> the 'push' part:
>
> hg push ssh://address@hidden/public_html/main
>
> So, if indeed I can't run Monotone on the server, I'll have to balance
> out Monotone's signatures against Mercurial's push. I'm not sure what
> I'd pick, but I think I'd lean toward the push (Mercurial).

But what does "security" mean for you?  I think monotone's security
has legs: if you use monotone, then you can trace every cert to its
signer, so you can find who made each assertion about each revision.
(Well, you can see which key was used, anyway.)  That feels
potentially of value to an open source project that might need to
defend itself.

But maybe you just want to be sure that nobody else has changed
something, in which case adding a signed tag now and again might be
enough.  Or just make a note somewhere of the most recent commit hash.

>> I work in an environment where we do code review (for every
>> change), so git's idiosyncratic (and awkwardly named) index, and
>> ability to revise commits (and ultimately automatically discard older
>> versions) is natural and valuable: it provides better support for the
>> workflow we used with CVS (preparing patches in a checkout, emailing
>> them out, then often revising them before integration).
>
> Interesting. I didn't know about that about Git. As a sole developer
> that feature doesn't apply to me. But it's interesting.

Perhaps it doesn't apply, though I'd be surprised if you didn't find
it useful.

> Do you use Monotone anywhere? I ask because you are, after all, in a
> Monotone mailing list.

I used to use it, but I don't any longer.