Time to Leave Monotone Behind?

[John Bailey]

Hi, all,

For almost four years now, we've been using Monotone as our source
repository.  Over that time, it's proven itself to work very well for
us, I think.  However, there have always been some annoyances with it.

Notable complaints we've had are the time it takes to pull our history
into a fresh database and the lack of compatibility with tools.  For the
pull issue, we hacked around this by using a cron job to generate a
bootstrap database and make it available for download, as this was
generally faster than a full netsync of our entire history.  Tools, on
the other hand, have been hit and miss.  I remember Mark having trouble
with meld after a new monotone release changed some of the 'automate'
functionality, breaking meld's use of it.  Other useful tools, like
monotone-viz, seem to take forever to be updated for even the tiniest
change in monotone.

Trac ingetration, in particular, has been a problem.  While a trac
plugin did exist for Monotone, that plugin routinely fell flat on its
face, requiring some black magic to fix it.  After some time fighting
that, we moved to viewmtn.  That has been a source of some frustrations
as well.  We've seen that viewmtn can be very slow, and we've resorted
to customizing it to improve some deficiencies we saw.  We also resorted
to writing our own trac plugin to link revision numbers in trac wiki
formatting to the revisions in viewmtn to make up for the lack of a
usable trac-monotone integration plugin.

Additionally, some of the more useful things that have been desired over
time, such as buildbot, are challenging to implement, to say the least.

It's been discussed a number of times over the last couple years that we
should consider moving away from Monotone.  At this point, I'm now
inclined to agree.  To that end, I propose that we move from Monotone to
Mercurial.  I'll come back to this in a bit.

As many of you who are in the XMPP MUC know, I've been working recently
on getting a good conversion from our Monotone database to an hg
repository.  I've done this a number of times before and consistently
failed, but thanks to Augie Fackler (used to be fairly heavily involved
in Adium), I now know exactly what the problem was and have been able to
work around it quite effectively.

Once I was past that point, the next step was to map all our 259 unique
authors, many of whom are really the same core group of developers, into
sane, consistently formatted author ID's.  I then proceeded into branch
name mapping.  In mapping branch names, mostly I just stripped the
beginning 'im.pidgin' off our branch names, but there were a couple
other minor tweaks, like making im.pidgin.pidgin become "default", to be
consistent with more "normal" hg repositories.

In fairness, I must credit Felipe Contreras for about 60-65% of the
authormap.  His prior work to convert our Monotone repo to git saved me
a crapload of time in mapping all the author ID's.  I took his author
map, made some adjustments, and then filled in the holes when I first
worked on the mapping last year.  This time, I just filled in the extra
authors the gaps (his map was 75-100 authors short of our current
state).  The branch mapping, however, was all my doing, thanks to the
use of 'mtn ls branches --ignore-suspend-certs' and some creative text
manipulation. Both of these maps would be useful for migrating to a DVCS
other than Mercurial, of course, with some minor adjustments.

As for my specific desire to use Mercurial, here are a few things we
gain (git may offer some or all of these as well, but I'm not
particularly fond of git, as we all know):
  * Significantly faster initial pulls (10 minutes vs 45 minutes for me)
  * Significant improvements in speed for essentially all operations
  * Trac integration via trac-mercurial plugin if we keep the one
    repository model.
  * Use of hgweb if we use a multi-repository model, with trac
    "integration" through similar means to what Adium has done
  * Ability to use "subrepos"--that is, we could do some creative things
    like split translations into a separate repository that translators
    have write access to but have that repository pulled into our source
    tree for us with the use of the appropriate hg extensions.
  * Ability to use stock buildbot for build testing of pushed revisions
    (although if we want to use buildbot on something other than the
    current im.pidgin.pidgin we need a multi-repo model, as buildbot
    doesn't handle hg branches that well).
  * Ability for potential contributors to clone the repository and host
    it somewhere like bitbucket to make incremental improvements that we
    can later review and incorporate upstream if we wish (the point here
    is that a workflow like this is easier in Mercurial than it is in
    Monotone).
  * The Adium guys can "fork" our repo and include it in their tree as a
    subrepo if they want.  The current Monotone process is painful for
    them, and using git would be only slightly less painful due to the
    increased speed.
  * We can add additional features to Mercurial as extensions if we need
    or want to.  This is relatively trivial since it's all python.
  * SSH-based authentication without needing to give every user their
    own shell account using the mercurial-server package.  Using this
    package we can control write permissions to specific repositories in
    a multi-repo model, and we can control who is allowed to create
    repositories on the server.  This is all done using SSH public keys,
    obviously.

What do you guys say?

For reference, here are some items to consider:
  * Author and branch maps, migration script, etc:
      http://hg.guifications.org/pidgin-mtn-conv-files/
  * First pass conversion (crude conversion with incomplete mappings):
      http://hg.guifications.org/pidgin-firstpass/
  * First pass repo above with completed mappings (I just ran hg convert
    on the firstpass repo with maps in place):
      http://hg.guifications.org/pidgin-firstpass-completedmaps/

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20110115/2587aa27/attachment.sig>