[Monotone-devel] Re: Mozilla goes mercurial

[Graydon Hoare]

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.

-graydon