Re: [Monotone-devel] Fwd: VCS comparison table

[Ulf Ochsenfahrt]

Hi,

I've read most of that thread, and I can't resist posting my opinion. I 
like monotone, because it has such a beautifully simple model:

You've got a repository, the repository contains branches and the 
branches contain revisions. Each revision has a globally unique 
identifier. The revisions form a directed acyclic graph (DAG) where each 
revision is a vertex and an edge goes from one revision to another if 
the first is a direct ancestor of the second.

A head of a branch is a revision that has no child in that branch. A 
branch can have multiple heads, in which case it is considered not 
merged. It can stay in that state indefinitely.

When I commit, I just create a new revision in an existing (or new) 
branch, that is, I add a vertex to the DAG. Regardless of whether the 
branch is merged or not.

When I work together with other people (or just with myself on different 
machines), I can do a push, a pull or a sync. These are the only (!!!) 
networked operations, everything else happens locally. A push identifies 
all revisions in the first (local) repository that are not present in 
the second (remote) one and transfers them. A pull does the same thing, 
just the other way round. A sync does both simultaneously.

As almost everyone who's been in the os dev game for a couple of years, 
I started out with CVS. I then discovered OpenCM. Unfortunately, that 
was just being rewritten at that time. So I switched to GNU arch (tla). 
That was nice, as long as it lasted, but it became clear after a year or 
so that tla was essentially doomed. Also, I had a couple of gripes with 
it: it would unpredictably sometimes require network access; it would 
sometimes require network access to different repositories; it didn't 
really allow real distributed operations - you had to have a master repo 
and a star topology. baz came along as the successor of tla (yes, I am 
oversimplifying here a bit) and we switched to baz. It didn't fix the 
problems I had with tla, but it was - at least - more actively maintained.

baz also didn't last long. The developers had already abandoned it and 
went to work on bzr (baz next generation, as it was called then). I 
refused to follow, as I didn't like some of the fundamental design 
decisions on tla/baz. So I started to look around for another rcs. And 
at that time, quite a number of new systems had sprung up:
darcs, mercurial, git, svn, distributed svn, monotone

I was looking for something that supported true distributed operation, 
windows, and disconnected operation, and most importantly that was 
stable enough. git went right away (no windows support). I was also 
uncomfortable with svn and everything svn-based - it only featured a 
Berkeley DB backend back then and I had only heard bad things about 
that. Also, the distributed SVN one wasn't usable at the time. I was 
uncomfortable with darcs, with it written in Haskell - although that is 
hypocritical -, and it storing a complete working tree in the project 
directory.

I'm not saying that those are bad rcs, but when I took a look at the 
monotone tutorial, I was an instant convert. It solves all the gripes I 
had with tla/baz and it has a beautifully simple and robust history 
model. Optimal support for disconnected operations. Distributed 
operation is what it does. And the history model (tutorial) explains the 
distributed operation very intuitively. I was a bit sceptical about the 
sqlite backend, but that turns about to be a good decision: sqlite makes 
a very mature impression, and having just a single file is a good thing 
for backup/migration (move to a new machine every 1-1.5 years) purposes.

Oh, and the discussion on that thread tells me that I was right to not 
go to bzr, I think that Linus is absolutely right about the rev number 
issue, plus I can't see a lot of advantages in a plugin architecture. 
For a rcs that is, in general, plugins make a lot of sense. But not if I 
want an extremely stable low-level tool.

And here's my monotone wishlist:
 - eclipse integration
 - HTTP support for pull
   (I don't particularly like the fact that I have to have another
   service / open port on my server.)
 - someone fix the DOS vulnerability in mtn serve
 - being able to pull just a part of the archive
   (one of my project is 20 MB and growing and pulling that over a
   dial-up line is bad, just bad)
   - even if that means that you can't perform all operations locally

Keep up the excellent work!

Cheers,

-- Ulf

smime.p7s
Description: S/MIME Cryptographic Signature