Archive for June, 2007
Looking over the companies that have purchased Pulse licenses, it occurs to me that a fairly large percentage of them are in the games development industry. In fact, it appears to me that game developers are over-represented. This could mean any one of a few things:
- For whatever reason, Pulse is particularly appealing to game developers, relative to developers in general. This could be the case, but given we have not made any special effort to target game developers it would be coincidental.
- I have underestimated the percentage of the industry that is involved in game development. Possible, as I have no hard data to back up my intuition.
- Game developers are more likely to adopt continuous integration than the average development team.
I could be wrong, but I think the largest factor is 3. To me, this means that developers in the games industry are more savvy than the average, at least in terms of applying helpful practices to their development process1. Looking one step deeper, I suppose the next question is why would this be the case? Are game developers smarter than the average bear? I don’t think I would make that sort of generalisation, but I would say I think it helps that they are in a “pure” development industry. That is, their core business is to create software, so naturally as a company they are focused on doing so as efficiently as possible. Development teams in non-software industries surely strive for efficiency too, but do not always have the full backing they require.
1 I guess I am biased, but to me continuous integration is one of those things every team should be doing.
If you’re going to build a “compelling replacement for CVS”, then you need to do two key things:
- Make commits atomic, with proper changesets
- Handle merging properly (e.g. support repeated, bi-directional and cherry-picked merges)
Sure, there are other things to improve on, and there is further room for innovation, but these are the two most fundamental features that CVS lacks. This is why I mentioned in my last post that I have been disappointed with the progress of Subversion. I am a Subversion user, and do prefer it to CVS. However, consider that the Subversion project was started in June 2000, and version 1.0 was released in February 2004. Proper merging support is long, long overdue. Thankfully, though, it is finally coming:
Current estimates target a 1.5 release with merge tracking in “late summer”, which I guess means August (people need to remember that there are two hemispheres…). I do hope that the new merging support is worth the wait.
Recently, Linus gave a Google tech talk on git, the SCM that he wrote to manage Linux kernel development after the falling out with BitKeeper. In the talk, Linus lambasts both CVS and Subversion, for a variety of reasons, and argues why he believes that git is far superior. In true Linus fashion, he frequently uses hyperbole and false(?) egotism as he lays out his arguments. This in itself could all be in good fun, but Linus takes it a too far. The even worse part, in my opinion, is that Linus confidently pedals arguments that are either specious or poorly focused. In the end, he just loses a lot of respect.
Now both CVS and Subversion are far from perfect. In fact, I personally dislike CVS and am disappointed with the progress of Subversion. Git clearly includes some advanced features that empower the user when compared with either of these tools. However, the way Linus presents the superiority of git is very misleading. Firstly, he throws out several insults towards CVS/Subversion that are plain wrong, such as:
- Tarballs/patches (the way kernel development was managed way, way back) is superior to using CVS. This almost has to be a joke, but sadly I do not think it was meant that way. CVS may be lacking many powerful features, but this statement ignores the many extremely useful features that CVS does have.
- There is no way to do CVS “right”. Only if you buy the argument that decentralised is the only way, which Linus does not convince me of one bit.
- It is not possible to do repeated merges in CVS/Subversion. It may suck that the tools do not support this directly, but everyone knows how to do repeated merges with a small amount of extra effort on the user’s part. I dislike the extra effort, but this is very different from it being impossible.
- To merge in CVS you end up preparing for a week and setting aside a whole day. Only a stupid process would ever lead to such a ridiculous situation; one that is not adapted to the tool being used. A more accurate criticism would be to say that CVS limits your ability to parallelise development due to weak merging capabilities.
Ignoring the insults, the very core of Linus’ arguments does not make sense. He claims the absolute superiority of the decentralised model, but the key advantages that he uses to back this up are not unique to decentralised systems. Almost all of the key advantages are much more about the ability to handle complex branching and merging than they are about decentralisation. The live audience was not fooled, and one member even questioned Linus on pretty much this exact point a bit over half way through the talk. In response, Linus starts off on a complete tangent about geographically distributed teams and network latency, leaving the question totally unanswered. The closest he gets is making some very weak points about namespace issues with branches in centralised systems (like somehow that would be difficult to solve).
The inability to answer (or perhaps the ability to avoid) important questions is in fact a recurring theme throughout the talk. Another prime example is when an audience member asks an insightful question about whose responsibility it is to merge changes. In a centralised system, the author is naturally tasked with merging their own new work into the shared code base. The advantage here is they know their own changes and are thus well equipped to merge them. In a decentralised system, people pull changes from others and thus end up merging the new work of others into their own repository. Linus is so happy with this question he quips that he had payed to be asked it. Such a shame, then, that he fails to answer it in any meaningful way. Instead, he waffles about the powerful merging capabilities of git (again, not unique to distributed systems). He then hypothesises a case where he pulls a conflict and instead of merging the change himself he requests the author of the change to do the merging for him. He concludes proudly that this is so “natural” in the distributed model. But hang on a second, the original point was that this would have actually been more natural in the centralised model: the author would have merged their own change and Linus need never have been bothered. Honestly, this is as close as you can get to stand up comedy when giving a talk about an SCM!
All in all, a very disappointing talk. Distributed SCMs are a great thing, and bring many advantages. The powerful merging that the distributed model has brought (through necessity) is something that other SCM vendors should be taking a good look at. This is no way to promote the distributed model, however. A more thoughtful view on the pros and cons of distributed versus centralised models, including what each can take from the other, would have been much more informative. My feel is that centralisation has many benefits for certain projects, and like most other things, the best solution would adapt the good parts of each model to the project at hand.
You are currently browsing the a little madness blog archives for June, 2007.