Xlib moved to git

[Keith Packard]

On Sun, 2006-02-19 at 08:47 -0800, Alan Coopersmith wrote:

> Since the decision to do this seems to have been made in private
> discussions, can you explain to the rest of us why git was chosen
> for us over subversion or mercurial, which seemed to be the leading
> contenders to replace CVS in discussions until very recently?

One of the advantages of our new modular world is that we needn't use
the same version control system everywhere, so this isn't some kind of
'global' choice.

In this particular case, we want to provide two parallel versions of the
same library, an XCB version (as discussed at the X developers
conference) and the existing version. Without some reasonable revision
management, it wasn't going to be easy to deal with.

So, a move from CVS was warranted, but perhaps a bit more email-based
warning would have been helpful in this case.

As to the selection of which SCMS to choose, I've frankly never seen any
group build a credible concensus around any useful system. In fact, I've
seen several groups (Gnome, recently) make ill-informed choices for
political rather than technical reasons.

I've selected GIT for my work for many reasons:

 1)	It has a credible track record with a real, large project.

This rules out things like Darcs, monotone, bzr, etc.

 2)	It has an obviously robust repository structure

This rules out svn, mercurial, CVS. Yes, mercurial is better than CVS,
but it still modifies existing files, rather than only writing new ones.

 3)	I have local support available (price == sushi).

The only local SCMS developer I know wrote git.

 4)	The CVS import tool captures the whole repository

Tailor doesn't handle branches, ruling out mercurial and bzr

 5)	It's very fast

This rules out svn+svk
 
 6)	The distributed model provides new developers tools.

Allowing all developers to share the SCMS, whether or not they have
commit access is a huge feature. New features can be developed and
distributed by people with no commit access as if they were peers in the
project, and not second-class citizens.

Now, the real key is that because the git import tools capture the whole
repository in a change-set manner, we can move from git to any of the
modern revision control systems in a straightforward fashion. So, if it
turns out one of the other systems, or some completely new one becomes
teh b0mb in the future, we can easily migrate from git.

My primary hesitancy in moving from CVS was repository-lockin, every one
of these new projects advertised CVS import capacity, but not perfect
cross-product compatibility.

We're now at the point where a substantial group of systems offer
essentially identical mechanisms, making moving among them easy if we
want to in the future.

Right now, git provides the capability, reliability and developer
momentum that we need to solve our immediate issues with some assurances
that future concerns will be addressed as well. In fact, with the import
of cairo into GIT, when concerns were raised about git on the git
mailing list, the developers addressed them responsibly.

I am not recommending a wholesale conversion from CVS to git; using a
few relatively low-velocity projects should help us decide where to
apply this particular tool, and how to manage migration of other parts
of the distribution. 
 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060219/d6a73ace/attachment.pgp>