[openib-general] configuration management for OpenIB

[Roland Dreier]

    Hal> A number of people have commented on subversion's limited
    Hal> ability to handle incremental merging and perhaps it's
    Hal> getting to be time to switch to another configuration
    Hal> management tool. git and mercurial have been suggested as
    Hal> possibilities for this. Are there others ? Any
    Hal> recommendations pro or con any of these ? Are there any
    Hal> issues with converting from svn to whatever tool is chosen ? 

I think for what we're doing, mercurial and git are the only two
systems we should consider.  Mercurial (hg) and git are quite similar
in most ways and are IMHO better than anything else out there for our
usage, namely a fairly big open source project with a lot of
distributed development.

I think the biggest advantage that subversion has is that its model is
very simple and easy to learn.  It will definitely take time for
everyone to get used to a distributed source code control system.

However, since git and hg track merge history much better, managing
multiple lines of development becomes possible (anyone who has tried
to develop on a svn branch knows just how useless "svn merge" is).  As
a bonus, git/hg are shockingly fast and allow completely disconnected
operation (ie you can work on your laptop on a plane and do commits
and everything).

There shouldn't be any issue in importing a pretty complete svn
history into either system.  We might want to just stick to getting
the history of the trunk into the new system, since the way svn
handles branches is different from git/hg, but I don't see this as a
big loss (since we have no merge history now anyway, and we don't
really have any active branches we want to keep alive).

One other question to think about is whether we want to stick with the
whole project in one tree paradigm.  As part of a transition, it would
make sense to me to move to a tree for the kernel stuff, a tree for
libibverbs, a tree for libmthca, etc.  The main obection to this is
probably that it makes it a little harder to tag a monolithic release.
But given all the pain that X.org is going through to split up their
tree, I would argue that making monolithic releases harder is a feature.

As far as the git vs. mercurial question goes, I don't have a strong
opinion either way.  Here are a few points to consider:

Mercurial pros:
 - Underlying data structures are probably slightly more efficient
 - Tracks history across renames

Mercurial cons:
 - Requires a gateway or some other conversion to merge with upstream kernel

Git pros:
 - Makes merging with Linus very easy
 - Probably bigger user and developer communities
 - Automagically deduces renames and copies

Git cons:
 - Requires periodic repacking of repository for efficiency

At the kernel summit, Linus said that he'll make a final decision on
whether to stick with git or switch to hg in a couple of months.
However, I don't think there's much chance of Linus switching (he is
just too happy with his git design).  In any case, even if we decide
to move towards git/hg, it probably makes sense to wait a couple of
months before picking between git and hg and see if the decision is
clearer then.

 - R.