Re: Which VCS besides git?

From: Bruce Stephens <bruce.stephens@isode.com>
Date: Mar 3, 2010, 12:12 UTC
Message-ID: <80fx4hbo4f.fsf@tiny.isode.net>
In-Reply-To: <94a0d4531003030358q276a8e9bue086a8ec06aba395@mail.gmail.com>

Felipe Contreras <felipe.contreras@gmail.com> writes:

[...]

> That's not exactly correct. Monotone works very differently; a
> revision doesn't include the ancestry, that's handled in a separate
> structure, so the revision hash doesn't tell you anything about the
> ancestry.

Not so. Long ago that was the case (ancestry was via certs), but that's not been the case for a long time. There are (in retrospect) obvious advantages in including the ancestry in the hash.

> In fact, a revision doesn't contain anything, the data is handled by
> "certs", and certs can be added later.

Revisions lack date, author, branch, commit message, but include ancestry and the actual changes (which files/directories have changed and how).

Show 8 quoted lines

> For example, it's possible to clone a repository and then add a second
> commit message to a bunch of revisions. The revision hash doesn't
> change. Instead, they ensure security by signing every piece of data
> about a commit (commit date, author, commit message). So it's possible
> to have multiple commit dates, authors, messages, etc. each signed by
> a different person.
>
> I'm not really fond of this approach :P

It has the nice feature that many people can create merges, and if they create exactly the same merge (from exactly the same parents) then only one revision results (just with multiple certs decorating it).

(Monotone has changed since I last used it but I think the above is still true. There's been discussion about larger certs (rather than having separate certs for branch, date, author, message, to have just one covering the usual combination) AFAIK that hasn't happened yet.)