CVS vs. Commercial Source Control? 43
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?
Bitkeeper is interesting alternative to CVS / RCS (Score:1)
is link to comparisons of Bitkeeper to CVS, Perforce, PRCS etc.
Distributed under variant of GPL http://www.bitkeeper.com/4.4.2.html they have restricitions on redistributing modified versions of their code, but this seems to only require Regression testing by Bitkeeper, to allow derivative works to be redistributed.
complement (Score:4, Informative)
Don't sell CVS short.... (Score:4, Insightful)
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.
Does do MS Visual SourceSafe (Score:1)
The biggest problem is that it corrupts it own database, Especially when you reorganise your project structure! How un-safe can your sources be in "SourceSAFE".
Re:Does do MS Visual SourceSafe (Score:2)
Re:Does do MS Visual SourceSafe (Score:2)
1. Treat file level and 'project' level labels differently.
2. "Lose" certain label types during "Archive / Restore" operations.
3. Actually create a new file revision for multiple labels applied to the same file version.
I could go on for hours about how much VSS really sucks.
-jerdenn
Re:Does do MS Visual SourceSafe (Score:2)
Re:Does do MS Visual SourceSafe (Score:2)
I think management is misinformed? (Score:4, Informative)
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.
Re:I think management is misinformed? (Score:2)
Re:I think management is misinformed? (Score:2)
CVS is bad... (Score:3, Insightful)
Try the following with CVS:
- Merge the changes that fixed bug #5212 from branch A to branch B. Don't merge any of the other development that has happened in branch A since then. Make sure to get all the files that were affected.
Simply put, CVS doesn't do this well.
Perforce is the tool I recommend, although CVS is fine if you only have one line of development at a time.
How I fix bug #5212 (Score:3, Informative)
Resolve conflicts and compile. Really, it's not that hard.
Re:CVS is bad... (Score:1)
Simply put, CVS doesn't do this well.
Can you tell us any tool which can handle this better? IMHO, in general case I can't imagine any better way than CVS way of doing this. Or is just that you don't know it's possible to get changes between any two versions and get it applied to some other version?
Take a look at Perforce. (Score:5, Interesting)
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.
Re:Take a look at Perforce. (Score:2)
For me, a vcs MUST have a command line client to be useful. I'm a big believer in reproducible builds and good version control and a command-line client go a long ways towards realizing that.
p4 client options (Score:2)
Most functionality is provided in all tools (except P4FTP), but the P4 command-line tool works the best for me, and I use it even on windows for a lot of stuff. There's also integration with Ant at this point for many commands based on running the command-line tool.
Re:Take a look at Perforce. (Score:1)
My team has mixed Windows, Unix, and Macintosh developers. It's been a relative pain trying to get a nice source control environment that we could all use relatively painlessly set up.
The Windows and the Unix users are usually no problem...but those bloody Macs!
Re:Take a look at Perforce. (Score:2)
At my last employer, some of the graphics people were using Macintoshes with Perforce with no problems.
Re:Take a look at Perforce. (Score:1)
If all developers are using "cvs edit" before editing a file, they will know.
You might want to read http://www.loria.fr/~molli/cvs/doc/cvs_10.html#SE
Tried them all (Score:4, Insightful)
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
Re:Tried them all (Score:3, Insightful)
SourceSafe follows the standard Microsoft line: it's pretty and fairly easy to use, but limited in a number of areas and not cross-platform (I used a Solaris version but it was very nasty).
PVCS is absolutely appalling.
I've not used Perforce, but I read that it's transactional, i.e., if you check in three files together it remembers that they're all connected to the same change. That sounds very useful.
You've been very harsh on ClearCase. I like the fact that you 'mount' the archive as a drive and use a filter to configure what you see. It's very powerful, although, as you say, it does mean you need a big server to support it. Also it versions directories, which means you don't lose history when you move or rename files.
Similarly, you've been overly nice to CVS! It takes the Unix approach to configuration: very minimal by default but can do wonderful things once you learn it. Or put another way, you can do just about anything with it given enough time. Statements like that, unfortunately, tend to scare managers. Also, I remain unconvinced about its scalability.
And, to answer a question in the original post, merging branches is always a pain, no matter which system you use.
Re:Tried them all (Score:2)
Let's see...
Mozilla has about 1000 developers (see http://www.cvshome.org/cyclic/cvs/proj-moz.html) and "many" source files.
OpenBSD http://www.openbsd.org/why-cvs.html claims 70+ developers working on 75,000 files that total 1349 MB.
Sounds pretty scalable to me...
Re:Tried them all (Score:1)
As you increase the number of developers, the chances of two people making conflicting changes increases. That's a fact.
From this, I could conclude that:
1. Those 1000 developers are not actually active, i.e., they have made edits but are not any more
2. There's not much activity
3. There's better communication than on a 'normal' commercial application
In reality, number "3" probably has the greatest impact. I've no problem with CVS' technical ability to scale to large applications, and I should have been clearer in my first post.
Re:Tried them all (Score:1)
One package I haven't found anyone commenting about was MKS's Integrity Manager. Has anyone used that and do you have any comments on it?
CVS book answers all (Score:3, Informative)
Re:CVS book answers all (Score:1)
It may be a good primer but there is an overabundance (but scattered) free documentation out there already
another vote for perforce, with some history (Score:3, Informative)
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 [perforce.com]'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 [rational.com]. 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 [accurev.com]. 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 [microsoft.com] 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 [merant.com] 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 [tigris.org]) looked promising, but it was too immature for us to use.
Bitkeeper [bitkeeper.com] 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 [mozilla.org] 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 [gnu.org], for example) are very weak.
Not really a technical thing... (Score:3, Informative)
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.
another vote for Perforce... (Score:1)
Perforce is great, but not for everybody. (Score:3, Informative)
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.
Killer 3rd party tools make CVS invaluable (Score:2, Informative)
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 [apache.org], 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 [apache.org].Also, like someone else mentioned, Mozilla.org has developed some killer online tools [mozilla.org] 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
The CVS Difference (Score:1)
The general process for using a source control system consists of three steps:
- Obtain a file from the repository.
- Modify that file on a workstation.
- Return the new version to the repository.
During which of these steps do development conflicts arise? The "traditional" source control systems say step two. Two or more people editing the same file at the same time will inevitably step on each other's toes. But therein lies the rub. Just because two people are working on the same file doesn't necessarily mean their respective changes will conflict. And notice I said WILL conflict. Future tense.This is where many source control systems have it wrong. Conflicts don't occur in step two. Multiple people never edit the same file. They each have their own COPY that they work with. The only way conflicts would happen there is if they were trying to use the same workstation. No, conflicts really happen in step three. If the file in the repository has changed since you've been working on your copy, then you might have a problem, and manually checking the files is the only reliable way to solve it.
So yes, CVS is different ... and for good reason.