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.
Don't sell CVS short, it may be quicker and cheaper to expand your existing CVS system than to replace it with a whole new system.
For instance, what precisely does management want to see? Can you harvest that information with simple scripts, or via calling programs at the various places CVS already provides hooks?
If the problem is poor documentation of the changes... that's a management issue, not a tool issue. Management needs to make sure people take this seriously - it should be a line-item in the employee review process.
As for the "problem" of multiple users simultaneously checking out the same files, that's a feature, not a bug. You would hope that adults would know how to work together, but in the real world almost every shop I've worked at with an "exclusive lock" source control system has had at least one jerk who would sit on locked files for days (or weeks!) at a time, then submit monster changes. CVS strongly encourages people to fix one thing at a time, and if someone makes a huge change then it's their responsibility to merge the differences.
Finally, I'm curious about the "work has been lost" statement. Is this because of poor practices (resulting in frequent change collisions and someone discarding code), or something specific to CVS?
P.S., unless you're in a completely homogeneous environment, the multitude of CVS clients for different platforms is a benefit that should not be overlooked. I've worked in several shops with CVS being used on Win9x, NT, and various Unix boxen without a problem. Most other solutions are either specific to a single platform, or very expensive.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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
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.
Source Safe
I've used multiple versions all the way back to 1994. (That was before Microsoft got their hands on it.)
Pros:
Decent client UI, fairly intuitive.
Easy to set up and administer.
Integrates well with MS tools.
"Project Oriented" -- maps well to your file system.
Cons:
Doesn't scale well.
Performs like dog crap unless you're running it on a local network.
Tends to get corrupted for no apparent reason.
Support for non-windows platforms is weak.
PVCS
Used in 1995 and 1999. The company I worked for in 1996 bought it over my strenuous objections then threw it away in favor of Source Safe.
Pros:
Industry standard, at least at one point.
Cons:
Slow.
Expensive.
Slow.
Arcane.
Slow.
Totally counter-intuitve. The client UI is, perhaps, the worst ever.
Oh, did I mention Slow?
Perforce
Have very little experience with this and none at all on a local network. I would rate it somewhere between SS and PVCS in terms of useability. Probably faster than both in a non-local network scenario. Disclairmer: We were running it over a vpn. Our client (owner of the repository) not exactly network whiz-kids. It took them months to get us additional VPN logins when we added more people to the contract. I suspect that, given a different client, Perforce might have been much better.
Pros:
True client-server.
Speed is okay provided you have decent bandwidth between client and server.
Cons:
Configuring it was a little weird.
Never quite managed to wrap my head around the way it wanted you to work. (Didn't use it for long enough, I guess.)
Clear Case
I have the least experience with this. I'd like it to stay that way, but... my current employer spent about a gazllion dollars buying into the whole "Rational Suite" idea, the gullible bastards.
Pros:
Uh, it's from Rational?
Cons:
Uh, it's from Rational?
Expensive. (Oops. Guess that's included in the previous point.)
Extremely difficult client configuration, at least on Windows. (Why does it need to run as a service on the client?)
Needs mondo hardware on the server.
Harder to administer.
The server crashes alot, at least ours does.
CVS
Those Linux geeks can't all be wrong, can they?
Pros:
True client-server. (Or not, your choice.)
Scales extremely well.
Free/beer.
Free/speech.
Requires very little server horsepower.
Flexible.
Plays well with others. etc.
Cons:
Doesn't handle binary files well.
Documentation leaves a little to be desired.
Like most Open/Free software there's nobody to point the finger at when something goes wrong -- this makes suits nervous.
Confusing use of the term "checkout."
The whole "concurrent" thing can take some getting used to.
I'm sure there are other pros/cons but I think that's enough.
--john