Version Control System Shootout Redux
At the Firefox Summit last week, we convened a session death match to discuss which version control system the Mozilla Project would use going forward.
There had been some initial work1 to specify our requirements for a new system, but now with work for Mozilla 2.0 looming, it was time to get everyone in a room and make a final decision.
I’ve been asked a few times about the outcome of the discussion.
For those that didn’t catch the Pay-per-view broadcast, here’s a review of the event and decisions, complete with screencaps:
The session, led by Vlad, Brendan and myself, started by clarifying the scope of the discussion. The two issues at hand:
- What version control system do we use for Mozilla 2.0 development?
- Do we convert to an interim system, to move off of CVS, for Gecko 1.9/Firefox 3 development?
So many choices to consider!
For Mozilla 2.0 work, it was decided that a distributed system is needed over a more classical, centralized system. This is due to a number of requirements, including increased developer agility2 and ability to share patches directly with each other. Additionally, distributed systems, to be coherent, much less usable/useful, need to solve the Complicated Merging Problem ™ up front, and there will be a lot of complicated branching and merging in 2.0 time frame that distributed systems, by virtue of their more advanced merging algorithms, support better.
This removes systems such as Subversion from consideration and and focused the discussion on Mercurial, Bazaar, Git, and the like.
While fun to watch, the battle among centralized systems was short.
Git was largely removed from consideration due to lacking Win32 performance and support, which is a requirement for us.
Vlad has been exploring Mercurial, which is used by the OpenSolaris project. There’s been a test-import of the trunk and initial testing seems favorable in terms of performance and our requirements.
During the meeting, a number of people asked for our impressions of Bazaar. Initially, we didn’t look too deeply into Bazaar, due to reports of performance issues from Sun’s investigations with OpenSolaris. As it turned out, some Bazaar developers were in town, and we met with them during the Summit to discuss requirements, Bazaar’s features, and other issues. Bazaar has some compelling features, but the performance and import story is still being investigated.
The battle of distributed systems is a bloody prospect…
We’ve made contact with both the Bazaar and Mercurial teams, and are beginning to work through import and usage scenarios. We’ll post more information on the scenarios as we work them out, and it may turn out that one system becomes a natural choice as the details start to fall into place.
For Gecko 1.9/Firefox 3 work, we discussed whether moving away from CVS to something like Subversion in the Q1 time frame was feasible, and then whether it was desired. There was a lot of discussion in this area, but given that Subversion fell out of the running for Mozilla 2.0, we resolved that it made little sense to spend time converting CVS to Subversion or some other system, only to convert it again to Mercurial or Bazaar.
Moving to RCS sounded like a good idea until we put the Lizard in the ring…
The plan of record, therefore, is to continue using CVS for Mozilla 1.8/Firefox 1.5, Mozilla 1.8.1/Firefox 2, and Mozilla 1.9/Firefox 3 development.
When we’ve shored up all the tool support and usage policy for the new version control system, be it Mercurial or Bazaar, then we’ll look at the feasibility of moving or merging development of the old branches into the new system.
In the original announcement, I said that we wouldn’t leave the room until we had a winner decided. That was mostly tongue-in-cheek, despite the fact that I think we all would’ve liked to have left the discussion knowing.
But going from a bunch of various version control system options and plans down to two, and having a concrete plan of action for Gecko 1.9 development and Mozilla 2.0 development was still a huge win.
I think this meeting illustrated that there’s going to be a lot of work involved in the conversion3 and because we’ve been so hand-wavy about which system we’re going to use, we’ve not thought about a lot of the details. But, we’ve got some concrete options to pursue, and the rubber is starting to hit the road, so I’m encouraged by that.
Having said that, I must admit I’m devastated that my favorite contender, ClearCase, got beat down so early in the running.
Poor ClearCase… we hardly knew ye…4
__________________________
1 Over a year ago
2 Admittedly, a fuzzy term.
3 bsmedberg and I estimated about 1.5 engineers for at least a quarter… probably more like two), and because we’ve been so hand-wavy about which system we’re going to use, we’ve not thought about a lot of the details. But, we’ve got some concrete options to pursue, so expect more information.
4 Images and characters chosen entirely randomly; don’t read too much into the pairings; I was never a MK player, myself.