During past days, under suggestion of Paolo Capriotti, we’ve been using git for the development of our project KBoard, trying to understand how decentralized development model works and what are its strengths and weaknesses. If you don’t know what git is, why it is promotes a completely different development model than cvs/svn and why it is worth considering, i highly recommend you to give a look at this talk from Linus Torvalds himself, where he explains why he decided to write it and what he wants a vcs to be able to do.
One of the issues with cvs/svn is that, since everythig goes in a central repository, nobody is allowed to commit changes that do not compile or break completely the code. The result of this is that most developers instead of committing their changes in a regular an logical way will keep modified files in their machine waiting for that particular feature X to be ready to go mainline. A commit “Implemented huge feature X” means that something is not working properly, this should not happen where a revision control system does what it is supposed to do.
One way around this is creating a branch for each new feature, but you won’t create a new branch in the main repository for each new feature that you are going to implement, would you? Much better would be if you could have your own repository where you will create a new branch for each new feature, and from which the mantainer of the project will be able to get your changes as soon as you tell him “Feature X is ready“.
This works very well in real life because people tend to create trust networks. For instance the toplevel mantainer of a project (Linus for the kernel) only trusts a few people, he cannot trust everyone. Each one of his friend will also trust another bunch of people, and so on. That is, once you have a patch for a feature X, you will just have to notify the mantainer of upper level that such feature is ready in order to propagate it up to the toplevel.
Another very important side effect of this new model is that it is exactly in the spirit of Mark Shuttleworth‘s talk at the aKademy: a sort of rithm, regular schedules and releases are required for an opensource project to proceed. But most kde developers are just doing it for pleasure, it is not fair forcing them to spend two months just fixing bugs because the release date is approaching. But in a decentralized development model each developer can just say to the release manager “features X,Y are ready, feature W requires testing, don’t include feature Z because it is not ready“, and the release will just slip out without pain.