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!
April 17, 2009 at 8:33 am
I still don’t see much difference. You could do the same thing in git by always committing on master, and not making any branches at all.
And as to branches, at least in our use case, we *want* branches! We don’t want to make changes to our main code base until we’ve had a chance to test and review the code. Always committing to your main code base can create headaches down the road. Yes, you can roll back, but it’s must easier to get a new feature right in a branch, then merge in later, than it is to push a bunch of broken commits, and then finally a working commit. As the policy in my company goes: master should never be broken (as defined by the test suite). If you’re always committing to trunk (as you propose in this post), then you’re going to have times when you’re propagating a broken trunk.
April 17, 2009 at 12:23 pm
Joshua: I still don’t see much difference. You could do the same thing in git by always committing on master, and not making any branches at all.
But then you end up with a centralized system, don’t you?
As for branching: some people love it, some people hate it. It depends very much on the scale of the project and company policy.
In large projects with many developers it makes sense to isolate small subgroups working on subcomponents. Here, Code Co-op offers similar functionality as git. Having a branch means pulling from the trunk and pushing from the branch. Both are supported.
It’s in the medium-sized projects that Code Co-op’s approach is much more convenient than that of git. When you have 5-10 people collaborating you shouldn’t be using branches. This is especially true in agile development, where collaboration is very close and every check-in is backed by unit tests.
March 13, 2010 at 12:11 pm
> When you have 5-10 people collaborating you shouldn’t be using branches.
That’s the mistake. And the mistake is to limiting people’s possibilities to manage the code they want. May be it’s really many things depends on company policy but limited possibilites can produce time delays in case what code is the best to commit in complicated path.
March 13, 2010 at 12:37 pm
> limiting people’s possibilities
I didn’t say Code Co-op doesn’t support branches–it does. But, in my experience, a small team is better off without branches.
I’ve worked in large teams at Microsoft, I’ve worked on open source projects, and I’ve worked in small teams. Each requires a different methodology and a different version control system. For instance, at Microsoft it’s a common practice to divorce development from testing. This encourages untested check-ins, which necessitate the use of branches.
In my team, at Microsoft, we always tested our changes. That required a system where all developers tested against the same trunk. We had to do it in a centralized, server-based system. Code Co-op accomplishes the same in a distributed environment.
September 18, 2010 at 7:46 am
There are reasons that Code Co-Op are not being used much compared to Git that go beyond advertising.
-Code Co-Op is Windows only, and developers are leaving Windows like rats on a sinking ship now that MS is forcing RAM hogs like Vista and win7 down its users throat. CC-O should be coded with a cross-platform gui toolkit like QT.
-Code Co-Op is not a nice sounding name. Honestly, try and imagine developers using the words Code Co-Op constantly in conversation, it doesnt roll off the tongue very well.
-Git is free. I dont expect that CC-O should be free, but there should be a non-commercial license so people can try out on long term projects.
September 18, 2010 at 11:35 am
-I agree that the name Code Co-op is not very appealing. Our clients usually call it co-op. Also, our URL relisoft.com is not easy to get right. These were bad marketing decisions.
-You are also right that free software, even if it’s lower quality, has virtually killed small software entrepreneurship. It’s an industry-wide problem.
-Windows is still a huge market though, so I don’t think this is a problem. We were, at some point, thinking about QT, but we would have to pay licensing fees. Besides, who on Linux would pay for a version-control system?
September 18, 2010 at 12:06 pm
>Besides, who on Linux would pay for a version-control system?
If I were you, I would approach Nokia and see if they will buy Code Co-Op to integrate it into their crossplatform QT Creator IDE
October 18, 2010 at 12:10 pm
Bartosz- Ive been thinking more about the idea of advertising and promoting Code Co-Op and I think your 30 day trial is pretty much worthless. No one can test something like a version control system in 30 days. Furthermore, most software companies are not going to try out any kind of software tool unless it is well known and been used on large and serious projects. The only way that is going to happen is if you start some kind of grass roots effort by making Code Co-Op available to reputable companies and universities for free so they can evaluate your product at length for their products. If I were you I would hire a marketing staff to do nothing but give free licenses to large companies and universities till the product takes hold and you can later start charging for it.
January 17, 2011 at 5:32 pm
Not all software companies have a lemming mentality, following just because a product already has a large following.
Sometimes a new idea will be tried because it is an outstanding new idea whose brilliance is easy to be seen.
Money is not the only measure of barriers to acceptance. Time is another barrier measure. Just because a product is free, doesn’t mean it is worth spending one’s time on it.
On the other hand, if a product looks like it will save time, it may be worth spending a little money.
Regarding centralized versus distributed development, the very idea that a company (a group of programmers) has “a” version of software to sell (or give away) at any one moment of time, in a sense implies some centralization: the object code sold is a compiled version of an agreed-upon or chosen version of source code.
But then when we put applications A, B, C, D, … together with an operating system, onto a computer, we have the situation again at a higher level. That is, instead of the efforts of several programmers being combined into one, the efforts of several “companies” are combined into one centralized pool, and have to play well together.
Maybe it’s more correct to think of a continuum of centralization and decentralization, where the term “centralized” means near one end of the spectrum, and “distributed” means away from that end. A development system might try to be completely centralized, but if there are more than one programmers it can never be. At the same time, a fully decentralized system is scarcely possible, unless it has only one programmer or no unique output.
The communistic countries of our youth tried to centralize all planning (analogous to “programming”), but they went contrary to human beings’ intrinsic individualized nature. Their systems were inefficient, people-wise, and bogged people down.
Programming tools which apply a lot of automation in a people-oriented kind of way make a lot of sense, from that viewpoint.
Such tools can be developed in a genetic algorithm kind of way (i.e. we try 10000 randomly mutated tools and only the best ones iterate), and/or by intelligent design (intelligently weeding out poorly fitting choices as best we can).
Even the cream of the crop of tools may lose out, though, in our world of trade-offs, if they are not made available to a lot of people.
A tool that saves a lot of people a lot of time (and/or money) has a lot of inherent power or attractiveness or worth.
In a way it can seem too bad that programmers (or anyone for that matter) have to be fed, clothed, housed, etc., for if we could all work for “free” the barriers to acceptance of our products would be lower. Then again, if nobody had to have any of the necessities of life, then why would we all need programs? Just for amusement?
I’m not sure this comment email has any endpoint answers. It’s more of a brainstorm about what the “centralized” versus “distributed” co-operative programming methodologies are all about.