[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Mozilla goes mercurial

From: Graydon Hoare
Subject: [Monotone-devel] Re: Mozilla goes mercurial
Date: Mon, 16 Apr 2007 14:49:40 -0700
User-agent: Thunderbird (X11/20070416)

Bruce Stephens wrote:
I note that they say:

    Monotone was ruled out relatively early as well, due to the
    similar [to git] Win32 performance issues and not wanting to split
    developer resources with Monotone fix- and feature-requests.

Does anyone know what the win32 performance issues were?

I can speak a bit about this; Paul's post oversimplifies for the sake of expedience (which is fine, he asked me what to say and I told him to oversimplify). I explicitly asked for monotone to be excluded part way through the process, and there were a bunch of reasons.

#1: Performance. I know we can never quite match speed parity with systems designed around byte copies of the storage format and seek-minimization. We touch the disk too much and our network protocol involves transformations to and from a canonical wire format. Even today, I just measured, and pulling net.venge.monotone using the 0.34 win32 native binary takes a half hour on my laptop disk. That's for 6000 small revs. Mozilla has hundreds of thousands, and it's a much bigger tree. Small scalar factors count.

#2: Reducing the number of candidates. This is weird to mention, but having 4 or more competing systems that are *almost* as capable as one another means that you waste time comparing them when you could be getting on with using them. Mozilla has an incredibly aggressive timetable for the next few years. We need to get into using a new system ASAP, and that means declining all but one of the candidates, by definition. We may revisit this later, or re-migrate somewhere else, when we have leisure. Presently we do not have leisure.

#3: I'm involved. This is bad for two sub-reasons: it will cost me time and social capital. If mtn lacks a feature, or is too slow, it's my fault and job to fix. If someone needs to learn how to do something in mtn, they'll ask me. Even if this is unfair (check the ChangeLog, I don't hack mtn much anymore) it's perceived as true. Currently I'm involved in a whole *pile* of disruptive changes to the mozilla code: from garbage collectors and JITs to static analysis and new VCSs. This means my schedule is already terribly fragmented, and I already look like an intrusive outsider messing things up in the mozilla community. Picking a VCS I'm *not* involved in reduces the conflict and contention.

#4: Monotone is experimental. It used to even describe itself as such on the homepage. I know we have more experiments left to do: distributed policy on overlapping branches in particular, but also likely changes to the network protocol for partial pulls, changes to the workspace for workspace merging and patch queues ... possibly a lot of stuff. I don't want to force us to adopt a "stable" stance too early (note: hg has adopted a "stable" stance at a point where it doesn't explicitly model file and directory identity; we could have done this 3 years ago as well, but it would have cost us dearly).

For whatever it's worth, I'm actually quite pleased with the result. I don't really see these systems as competing as much as co-evolving, and enabling massive increase in the rate of free software evolution. In the early 2000s, anyone I described this sort of tool to thought it was crazy and would never work. Merge *after* commit? Branches with *multiple* heads? *Content addresses* in history graphs? *No* canonical servers? Now all this is the standard, and we're quibbling over who does it fastest. Who cares? The battle is won: DVCS technology works fantastically well -- using the model we pioneered -- and free implementations of it are absorbing many major projects. That's cause for celebration.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]