Monotone analysis

[Luke Schierer]

On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote:
> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote:
> > = Git recommendation =
> 
> Sure monotone is slower, but is it fast enough? Sure the monotone db is
> bigger, but is it really that much of a problem? Maybe there are less
> tools for monotone, but the extra tools for other DVCSs are worthless if
> we don't plan to use them anyway.
> 
> While I don't dislike git or anything else, and think that starting with
> monotone now is a little silly, I think the important thing here is
> whether the cost of switching is worth it. Many of us spent quite a
> while to learn monotone already, and it's hard to spend time to learn
> something else unless it's clear that there's significant return. Also,
> if we switch to X now, should we switch to Y when that becomes _better_?
> 
> Pidgin isn't in the business of developing DVCSs. If monotone becomes
> not good enough, or if there's a clear winner in the DVCS space, then
> ya, maybe it's silly to keep using monotone then.
> 
> -khc

Git must have really improved since we made the switch to monotone.  I
did some digging around, and since I am quite nearly an invenerate
pack-rat, I found a working copy of a git repo I created back when we
were evaluating which dvcs to use.  The git repo from then is 649M, my
much much newer monotone database is only 244M.  

I recall that the size of a git database was such a problem that the
kernel developers weren't even trying to use a database with an entire
history in it, they dumped all their historical stuff in one repository
and had another with just the 2.6 stuff in it.  

Looking at it now, it appears that their basic work flow is that anytime
someone does significant enough work that someone else might want to
help them with it, before it is merged into the one head, they create a
new download target on git.kernel.org.  Though I could be wrong here,
I've spent very little time thinking about git since we made the
decision, and I'm a little foggy on how it works now.

Still, there are some important things to remember here.  We spent
considerable time and effort evaluating our options when we made this
switch.  I am a little tired of the idea that we made it relatively
arbitrarily.

At the time there were a number of apparently equally viable DVCS.  I
looked at _all_ of them, including git, bzr.  hg, at the time, was not
even used by redhat, and did not appear to be really viable, so I admit
I did not look at it.  Of the ones out there, while a fair few had
started implementing subversion -> $dvcs support, only two had _working_
support, git and monotone.  At least, several had support that
_appeared_ like it it _might_ work for much smaller repositories, but
only two could handle _ours_.  We wanted to have the full history
available to us.  

Of them, git, at the time, as you claim this is solved, required almost
a full CDs worth of space just for the repository.  Unlike monotone,
this repository has to be stored _per working copy_.  That means if I am
working on head in pidgin.my/ and gobjectification in pidgin.gobject/
and 2.4.x in pidgin.2.4/ then I incur this cost 3 times, whereas with
montone I have one database, and so incur the cost once.  Monotone
_could_ be larger than a git repo and still be a clear winner (space
wise) on this alone.  In fact, this was one of the deciding factors in
picking monotone over git.  Several developers expressed a very strong
dis-interest in re-learning their work flows to be able to effecitently
work on multiple projects in one working copy. 

Another consideration is that downloading an ISO's worth of data is, or
at least was, non-trivial for a substantial number of people, again this
was a concerned expressed by some developers at the time.  Would you
really consider working on pidgin to contribute that one patch if you
had to download that much just to get going with our DVCS?

While I have always been attracted to git _because_ it is used by the
kernel developers, and I figure that this fact will ensure that it
continues to be improved on, and ensures that it will continue to have a
substantial body of users who are familiar with it, I really don't think
our choice of monotone was unreasonable given where we were at the time.

I wouldn't mind switching now if 1)there were a clear benefit to doing
so and 2)a degree of certainty that we won't be switching again in
another couple years.  That being said, I don't think we want to throw
away our work on trac _now_, so we'd want to make sure all the pieces
were in place for trac integration _before_ the switch.

Luke