In the first few weeks of my company's existence, I was given the task of setting up a source code management system. After evaluating several alternatives, I decided to go with Razor from Visible systems. The main reasons were the modest cost per seat and the relatively good integration of bug tracking with code management. A trial version was available and we tried it out for a few weeks. The results of the trial were encouraging but ultimately Razor did not go over well with our developers when put into production. The main problems at that time (mid 2000) were:

• The CLI client tool was hard to use (compared to CVS). Since a number of our users had worked with CVS, this was an important objection.
  
  
• The Linux GUI client was a little clunky to use.
  
  
• It turned out that the client and server had to be mutually reachable over the network. From what I could make out, this was necessary to allow the GUI to change file status in real time. Since our developers sometimes needed to access the server through a NAT (Network Address Translation) gateway, this turned out to be a big problem.
  
  
• One more administration annoyance was that the Razor server was locked to a particular machine. Since our IT infrastructure was far from stable, this caused a lot of problems since each transfer of the license had to be approved by Visible.
  

Due to these problems, and also general resistance from the developers, we switched to using CVS for source code management. Since we were still in the experimental phase, there was no urgency in setting up a bug tracking system (which we lost by abandoning Razor).

Our CVS server is configured so that every CVS commit resulted in an email containing details of the commit being sent to all developers. Developers generally save commit emails in a folder in their mail reader and use the built-in search facility as a sort of a database to search for commit data.

In addition to each developer's private store of commit messages, we also use a tool called Bonsai that saves CVS commit messages in a relational database. A convenient web UI is available that allows one to perform complex queries against this database. Bonsai is invaluable at release time and when trying to determine whether a bug has actually been fixed.

There are many problems with CVS and these have been adequately described elsewhere, but the main issue that one needs to be aware of is a cultural one. CVS is great as long as its used in the way that its supposed to be used. In general CVS works best where the philosophy of development is along the lines of "it's better to ask for permission than to get permission". CVS is not a tool that works well with a "command and control" approach to managing development.  Despite this caveat, there will be times when it is necessary to lock a branch --  for example, when finalizing a release. This kind of locking can be added by using server side wrapper scripts although we have not done this so far.

The other big problem with CVS in the context of commercial development is the lack of any means to group commits together (i.e. changesets). When finalizing a release, for example, it's important for the release manager to know exactly which bugs have been fixed and which new features have added. This problem can be overcome by having developers include a reference to a bug or feature in the commit comments. If this convention is followed diligently, it is possible to track down all commits for a particular bug or feature with the help of Bonsai. However, mistakes often happen -- usually at the worst possible time. Developers may neglect to include a bug reference or may reference the wrong ones.

If we were starting today, and decided to use open source tools,  we would definitely use a better tool such as subversion. We have considered switching to subversion right away but have delayed a decision since the advantages do not appear to be compelling for now.