I just watched a very interesting video of Linus Torvalds talking about version control systems. No, he never mentioned Code Co-op–in fact he incorrectly stated that the only commercial distributed version control system is BitKeeper. In reality, Code Co-op is one too, and it’s older than BitKeeper. I will forgive Torvalds though, because Code Co-op was never as heavily advertised as BitKeeper.
Torvalds is very opinionated and quite rude, but when he’s right, he’s right. He totally destroyed CVS and Subversion (he called the creators of Subversion morons–ouch!). He didn’t have any warm and cuddly words for Perforce either. Essentially, he considers centralized version controls brain dead, to which I can only say, “Amen!”.
Then he described his own baby, git, the distributed version control used in maintaining the Linux kernel. It was a lot like listening to the description of Code Co-op, except for git’s lack of solid GUI and heavy reliance of merges.
Like most people, Torvalds equates a distributed version control system with everybody creating their own branches and then merging them with other people’s branches, until the final merge is performed by the highest priests of the project (in the Linux kernel, Torvalds is the über priest). This is probably the best model for large open source projects, where, in Torvalds’ own words, 99.9% of branches are rejected anyway.
Here’s where Code Co-op stands out from the crowd of distributed systems. Yes, it supports branches and merges, but most of the development is concentrated on a single trunk. It’s the difference between having multiple databases that have to be merged by hand (git), and having one replicated database (Code Co-op).
Replicated databases are the bread and butter of distributed systems. One of these days I will describe the distributed protocols used by Code Co-op. For now, a replicated database behaves like a single database with copies (replicas) distributed to multiple machines. A system of protocols implemented by Code Co-op takes care of propagating changes between replicas.
The best way to think about it is to imagine that every check-in is like a virus that first infects your copy of the database. From there, the infection spreads to other replicas, until all are infected. All this happens pretty fast and automatically.
The only time user intervention is required is when two such infection collide. At that point the stronger of the viruses wins, and the weaker one creates a temporary mini-branch. Such mini-branches have to be merged. Note that merging in Code Co-op is rarely needed; in git, it is the basis of change propagation.
If you really need a branch, Code Co-op makes it easy too. You may work with Code Co-op just like with git–pulling and pushing changes between branches. But you don’t have to!