I have been using CVS for the revision control of some of my group projects. Sorry to disappoint CVS developers, but I have to say that the piece of software sucks! Then I switched to Mercurial and found that it is very handy. Sometime back, one my friends suggested me to try GIT. And now I can say that GIT is the best software for revision control.

Main Issue with CVS (and SVN)

CVS will drive you crazy if you are managing a large open source project. The main issue is that it wouldn’t support atomic operations. This means that the system won’t be ‘stable’ if one of the commits goes wrong. Also, I need to worry about issues like accidental checkin. Here in this webpage, you can see some of the operations that you can perform using CVS (it also illustrates basic operations like branching and merging). I suggest you to download a large open source project and try maintaining it (just by creating another CVS repository). You may also ask your friends to contribute so that you can test all the branching and merging. Believe me, it will drive you nuts!

Branching and merging

Beginners may not have tried branching and merging before. Let me explain this process for you. Whenever you are developing or improving a feature for an existing project, you create your own branch and start working on that code. Once you have successfully completed the coding, you can request the project maintainer to review the code and ‘merge’ the new code to the main trunk of the project.

Atomic commits allow you to do this process yourself so that the change will be reflected in your tree. CVS is not supporting this feature.

Distributed Control

In case with CVS  there is only a single repository (called the central repository). This actually kills the spirit of open source development. And more over this topology fails if you have a large number of developers who are not properly interlinked.

GIT has a distributed environment. This means that you can download the GIT repository from the repository of the project administrator and create a new repository and add a new branch to it.

After the testing, you can simply ask the project administrator to ‘pull’ from your repository. You can also view others code and compare them with yours. If you want to add others code to your repository, then you can use the ‘pull’ command yourself.

Hence you will be have complete freedom to develop and contribute for the project.

Network of trust

The whole idea of a distributed revision control system is pivoted around ‘a web of trust’. This means that you can pull from the people whom you trust and they will also be doing the same thing. Hence there will be a virtual ‘trusted’ network formed.

Is distributed control a good choice?

If your company is a corporate entity with strict control over the ‘commit processes’ and development, then distributed control is not required in your case. But you can still use GIT without using this feature (by putting a restriction). Moreover, distributed control mechanism is not preferred if your organization care much about data security. In all these cases, it is assumed that the development team consists only up to a couple of dozen people and are properly ‘connected’.

But service providers like SourceForge should never opt for revision control systems like CVS.