Yeah, Linus does enjoy taking that attitude. Just a shame he overdid that rather than talking about the really interesting parts of git.

Re: CI vs branching, I am as big a fan of CI as anyone. Heck, I started a company to make a CI server :). I also take your point that CI can be an alternative to some forms of branching. However, there are other forms of branching that CI cannot replace. For example, maintenance branches for old release streams and development branches for experimental/long term projects. In these cases developer teams cannot avoid parallel development, and there will always be merging.

Taking things even further, in an agile approach teams are encouraged to start simple and refactor mercilessly. This can be painful, however, when there are parallel codelines. Refactoring is the enemy of parallel development as the merging tools are not smart enough to handle it. This is a big enough topic to be worth its own post!

Personally, I find git, mercurial, monotone etc very interesting, but I’m very happy with subversion as it is, even without merge tracking. The thing is, coming from an XP background, I’m really into continuous integration, so I try not to use branching.

There are at least two ways to deal with the pain that comes from the merging that goes with branching: continuous integration or excellent merging tools.

If you do CI, you avoid working on a private branch, you just work in your working copy, synchronise a couple of times a day and use tools that make this easy. Not everybody likes this, but done properly (with unit testing, TDD etc), this is a breeze. Small changes, rare conflicts, no poisoning of the trunk. Subversion is excellent if you want to work like this.

The people who like git take the opposite approach: instead of avoiding the pain of merging by not branching, they accept branching as natural and develop excellent tools to make merging easy. If you like to work the way the kernel developers do, Subversion is probably not the tool you want to be using.

Some people will feel strongly that distributed development is better than CI, just as I think the opposite is true. But clearly, both methods can be very successful.

Git is a more powerful tool in the sense that it supports both models well. However, since I do not need the extra features it offers, I’d rather use Subversion, if only because it has nice GUI’s such as Tortoise. This will undoubtedly change however, as I’m sure the git people will come up with decent GUI’s as well.

Just my 2 cents.

All of the so called centralised version control systems will eventually have the ability to perform local commits (if they don’t already) at which point they become similar to the decentralised systems.

Any decentralised version control system can be considered a centralised system if you call one particular node the master (in the Linux case, it would be Linus’s tree).

I’m skipping over the differences in processes involved: e.g. push vs.pull, but they aren’t really anything to do with whether it’s centralised or not.

My biggest concern with git is that you have to have the entire history of a project downloaded locally. They say it’s fast so it doesn’t matter (I haven’t tried it) but it doesn’t sound like something that will scale (history only gets longer). I realise that you can do shallow copies with git but I believe that leaves you with a crippled local copy. It strikes me that whether history is present on a local machine is purely a caching issue and so the absence of it shouldn’t be a problem.

I think the most interesting thing about the distributed model is the extra challenges it presents to the implementation. These challenges have given birth to solutions that would also be very useful in a centralised environment. Layering a partially centralised process and/or UI on top of the distributed technology - hiding some of the unwanted complexity of distribution that is not always needed - could provide a compelling replacement to traditional centralised SCMs.