[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Fwd: VCS comparison table
From: |
Ulf Ochsenfahrt |
Subject: |
Re: [Monotone-devel] Fwd: VCS comparison table |
Date: |
Fri, 20 Oct 2006 14:37:47 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060927) |
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