CVS vs. Commercial Source Control?

Knight2K asks: "My company is currently using CVS to handle our code repository. The project managers, however, are unhappy with some problems with the system. Most of the developers appear to feel that CVS does what they need just fine, but don't seemed to be bothered by switching to something else. It seems to me that CVS handles part of these things, and cultivating a culture of responsible revision handling would take care of others. I would like to be an advocate for CVS here, but I don't want to just promote the Open Source solution if there are legitimate reasons or advantages to switching to a commercial project."

"The project managers disliked CVS because of the following:

• Inadequate logging. (Management wants to be able see who is checking in what, how often, and how, track known issues, ChangeLogs, etc...).
• Controls for branching and merging are awkward
• Files can be edited by multiple users simultaneously without checkout.
• Work has been and will be lost due to lack of true version control.

So my questions are:

• Has anybody made the jump from CVS to a commercial source code control system (or vice-versa)? Why? How do they compare to CVS?
• Anybody have procedures or processes they can share for handling branching and locking? How about tools to make the process easier?

I realize the issues listed above are a little vague. If it helps, we work on Java web applications and develop on Unix and Windows with a variety of different editors. Any insights into source code control would be great."

Comments

Take a look at Perforce.

[MemRaven]

I know somebody else has mentioned this already on this statement, but you should really take a look at Perforce. They've got high level technical overviews and comparison with CVS. But it fundamentally solves everything that you say you're lacking right now:

• Logging: P4 is much more server-centric than CVS, so at any time you can see what files are opened by which developers on which machines, which is one of the things that you're looking for. In addition, the ChangeList metaphor that it uses for atomic changelists ties the whole thing together by allowing you to easily do lots of tracking by changelists. Finally, you can do a lot of reporting with the built-in tools, such as "show me the last 10 submissions by Bob" or "show me all changes to affect that branch of development".
• Branching and Merging in Perforce is great. Fundamentally, it keeps track of the different file revisions as separate subtrees of the system. So, for example, you can have //dev/... (the current development branch), //dev/v2/... (version 2), //dev/v3/..., etc. Or you can have //dev/..., //v2/..., //v3/... You can pick and choose precisely where you have branch points however you choose, and because that mapping ends up affecting the client's file hierarchy, users have the same hierarchy for different versions of the code hierarchy at the same time. Merging is incredibly easy (we currently have 4 active branches of development, and it's reasonably easy to keep them all in sync).
• I think what you want is to be able to see who's working on something. Let's say you've got a binary file checked into CVS. Two people might be working on it. How will they know? Are they expected to email everybody else that they're working on it? What happens when they try to reconcile the changes? P4 handles this by keeping track of who's working on what file, WITHOUT locking the files. So you can have two people working on the same file, but they at least KNOW about it at the time that they're making their changes. Furthermore, for troublesome binary files, you can now have a file attribute on the server say "multiple people can read this file, but only one person can have it checked out." You can control that on a per-file, or per-file-type (such as "all .doc files") basis, which can be huge for the few files that inevitably have those problems.
• I'm not sure what you're talking about with the lack of true version control, but P4 has a very strong transactional background, and perfectly atomic submissions (which CVS does not). It's impossible to synchronize to an inconsistent state without specifically wanting to do it. If you're talking about RCS file corruption, P4 stores digests of all the revisions of all files in the depot in order to ensure that it can recover from RCS corruption (or at least detect it, I'm not sure since we've never had a case of corruption there).

There are even tools for automatically taking a CVS hierarchy and putting it into P4. I've not used it, but apparently it's quite easy to do.

The biggest change that people I've seen always notice is the fact that with CVS, you just start editing files and it'll figure out later how to work that into the server. With P4 you have to tell it, which is not that great. However, there's a tool called C4 which a couple of our engineers who are most comfortable with CVS use which presents a view almost identical to that of CVS (except for the specific P4-isms), so that the learning curve is greatly decreased.