Slashdot Mirror
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.
- 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?
Instead of ditching CVS, you might want to look at some tools which can complement it. The Mozilla project has several which might address some of the complaints.
Inadequate logging. (Management wants to be able see who is checking in what, how often, and how, track known issues, ChangeLogs, etc...).
CVS logs all checkins. If the comments supplied with a checkin aren't adequate yell at the developer. A different/better tool won't make the slightest difference here.
CVS can also send notifications to people when various events happen (I think CVS calls them triggers). If someone makes a change to globals.h, for example, everyone would be told about it.
Controls for branching and merging are awkward
Has anyone tried a GUI frontend? I like the command line but I've set up a couple people here with WinCVS and it looked pretty good.
Files can be edited by multiple users simultaneously without checkout.
As someone else has pointed out this is a feature. And it's very good at merging changes. If it can't, it tells the poor developer to do it manually.
Work has been and will be lost due to lack of true version control.
This just can't be right. Version control saves work, that's what it's there for.
Keep in mind that CVS handles some of the largest Open Source projects in the world, like Mozilla, Gnome and the Linux kernel.
"The cost of freedom is eternal vigilance." -Thomas Jefferson
I grab the pre-bugfix label from CVS. I do a CVS diff against the label "bug5212" (indicating the verision with the fix). This generates a patch file. I switch to my other branch and apply the patch.
Resolve conflicts and compile. Really, it's not that hard.
sigs are a waste of space
Most if not all of your concerns are answered in "Open Source Development with CVS" (Coriolis, ISBN 1-57610-490-7), most of which can be downloaded from here.
Ryan T. Sammartino
"Ancora imparo"
I recently had the job of evaluating what SCM system to use for our company. We were using CVS at the time.
...
I believe that the complaints your bosses have about logging and concurrent editing can all be fairly easily fixed in CVS.
The major gripes we had with CVS were:
. slow (see below)
. merging between branches was miserable, because the system didn't keep track of what had already been merged
. renaming files lost all the history
. windows interface was cumbersome
We actually worked with a system layered on top of CVS that allowed us to submit batches of files at once, in a single transaction. This was the major cause of slowness, and CVS didn't really support transactions, so in some sense we were just fooling ourselves. The other major cause was doing a 'cvs update' on a large tree could be slow.
Most of the problems we had could've been fixed
if we spent the time to fix it. Some (transactions, renaming) we couldn't really fix at all. But, when I looked at everything I wanted to fix in CVS, I found that I had just described Perforce's feature set, and when I looked at how they implemented things, they did it like I would've. Plus, comparing the cost of Perforce (relatively cheap) to the time it would've taken us to implement the same features
So, we switched to Perforce, and I've been (more or less) happy since. The branching structure is a little weird (compared to ClearCase's, which is the most intuitive I've seen), but we're learning to live with it.
At a previous company, we used ClearCase. This was also a fine product, and it does a few things that no other product does, but it's very expensive, and a major hassle to administer.
ClearCase (at least in the mode we used) implements its own filesystem, and can provide a level of security that the others just can't. But, is this worth paying 10+ times the amount for it?
I also looked at AccuRev. This was about on a par with Perforce, and had one or two features that looked really cool. But, in the end, Perforce won mostly because we went with the product that had bigger market share and more people had used it before.
VSS wasn't an option because we're a mostly linux based shop, and because I had heard many of the complaints that others are making as well.
PVCS I think is mostly an also-ran in this day and age. I think most new source-system users use one of the other previously mentioned systems.
One new open source project (Subversion) looked promising, but it was too immature for us to use.
Bitkeeper also looked interesting, but not enough so to beat out Perforce or AccuRev.
Another thing you might want to consider is how well the SCM integrates with a change mgmt system (or bug/task database). Perforce has a simplistic change database built in, but it's good enough for what we want it to do, and it can also be used with Bugzilla and a few other systems. Of course, CVS and at least ClearCase can do these as well. I've found Bugzilla somewhat cumbersome to use on limited inspection. Other freeware systems (GNATS, for example) are very weak.
Inadequate logging. You can add extra technical measures to increase the quality of your logs. We have a system here where each comment has to have a bug report number in it. CVS checks to make sure the number is valid and in the bug report tool you can see which files have been modified for that defect.
That does mean that every change requires an entry in your bug database. This can be a pain for minor, ad hoc changes (but there's an argument that you shouldn't be making changes like that anyway).
Controls for branching and merging are awkward. Frankly, branching/merging is difficult in all the tools I've come across. CVS appears to be above-average in this regard. To paraphrase Tommy Cooper: "Slashdot, it hurts when I branch/merge." "Well don't do it then."
Files can be edited by multiple users simultaneously without checkout. Another management thing. You shouldn't schedule work that's likely to make significant modifications to the same chunk of code at the same time. If team members talk to each other this isn't a huge problem!
Work has been and will be lost due to lack of true version control. I'd bet that more work would have been lost without CVS. I think you need to find out what your manager considers "true version control" to be before anyone can answer this.
I've used perforce for years now, as far back as when it was called 'p3'. I find it absolutely invaluable and could not live without it for doing my FreeBSD development work on. Right at this instant, my development p4 repository has about 40 active branches on it. One has been alive for 2 years now and part of it has just recently been committed to the main FreeBSD tree. I must have done at least 80 to 100 merges to pull in the freebsd base changes into my branch. I am constantly suprised at how easy/painless this is compared to CVS. Yes, you can do it in cvs as well, but you have to mess around with tags etc. With perforce it is a no-brainer. In other cases I have a branch of a branch of a branch. Perforce was designed for this so that branching is so cheap and easy that it is quite practical to do *every* non-trivial feature development in a seperate branch.
The only weaknesses that I regularly complain about with perforce is the relatively weak command line interface (compared to cvs, for example) and the lack of detached operation capabilities. For a corporate development environment the latter is generally harmless, but when you take a laptop on a plane or to a conference it can be a pain.
p4 does require that you think a bit differently compared to traditional SCM's but the payoff once you've learned it is fantastic. But people who are doing the occasional patch here or there are not going to see these benefits. For them they may as well keep on using cvs.
The Apache project has created many scripts for use with CVS which helps out a lot with the types of things you describe. To get some of these tasty treats check out their cvs web interface, or check out their CVSROOT module directly. I believe they encourage people to use these scripts (it is Apache, after all :)
Apache provides:
- Access Control Lists
- Commit Message Mailing System
Detailed instructions on how to install the scripts can be found in the README.Also, like someone else mentioned, Mozilla.org has developed some killer online tools for managing source code with CVS. You get things like:
- LXR - a "massively-hyperlinked source code browser that lets you cross-reference function and variable names"
- Bonsai - a tree control "tool for watching up-to-the-minute goings-on" in CVS and "viewing checkins and log messages, reading diffs, etc."
- Other tools like Tinderbox and Bugzilla
If you end up staying with CVS, you will definitely want to check these out. Hope this helps.--Micko