Slashdot Mirror
Clearcase vs. CVS?
briany asks: "I have been asked to evaluate Clearcase vs. CVS. I am wondering what kind of experiences people have had (good and bad) with either product, or if there are other products that should be considered.
The projects that will be stored are rather large (10+ GB) and need to be accessible from Solaris, Linux, and NT/Win2k." Of course, it should be mentioned that Clearcase is available for Linux, as well as other unix clones.
I don't have any experience with Clearcase, but they have a free online demo, and a free demonstration cd-rom offer at http://www.rational.com/tryit/index.jsp
Daniel
Clearcase cost a LOT of money and takes quite a bit more administration. For your trouble, you get file locking. Yes, that is sarcasm. No one on the team who was using it at the time liked it.
cvs simply requires a little more developer time to do file merging. I personally really like it.
I've used CVS a lot, but never in big projects. I was told I had to use clearcase once, and the sysadmin botched the install so bad I dumped it and they backed off when I threatened to quit. (I was on a separate project with only a few programmers who were all happy with CVS, so the rest of the dev staff could use punched cards and it wouldn't have bothered us.)
For what it's worth, I understand one big difference is that clearcase automates things like tracking the compiler and lib versions, so you could go back a long long ways to reproduce a really old version byte for byte. Another difference is that it eliminates dup copies of source and object files among the staff, potentially saving space and time. How well this works in practice, I don't know, and I've never felt any need for it.
The other comment about needing more sysadmin work is certainly true. In addition to the loon who clobbered my system with the bad install (Sun OS, early 90s), a different sysadmin, purportedly her boss, twice erased the entire clearcase repository. Apparently it was too tricky for the average bear. I see that as two strikes against clearcase just from the point of not being very maintainable, and hope to never see it again.
CVS is good. Text files you can edit in an emergency or just in readonly mode to see when things happened, as opposed to SCCS, and it is just plain good. Be happy with CVS. Your repository is valuable -- don't give up control.
--
Infuriate left and right
I have used CVS for some time now, was evaluating it vs. clearcase and found it to be pretty easy to use and quiet powerful. I have worked with it on a client/server project, 100+ developers and code in C/C++ for the server, and JAVA for the frontend. All together this was a rather large Telecommuncations system and it worked pretty well using CVS. NOTE, even with is being an extremely large (Hell Informix used it as a sign of large installs, and so did Sun for its use of EU10K's) cvs did pretty well, the learning curve is rather simple and is pretty powerful for most purposes.
I have installed it and am running it where 20 developers are using java/jsp and it works fine for our product. Images can be a bit annoying, but all text data rocks!!!
Now about the size of your project ? 10G+ was it ? ? exactly what are you going to be storing ? ? Thats a whole lot of code, and as i keep telling ppl. here, data does not belong in the repo..... only code that you want to get back to.... DATA should be kept on a FS with good naming, like a simple (filename)_(date)_(version).* BUT ten G's is going to be one hell of a freaking checkout!!!!
Non-Deterministic Finite Automata
I'm working in such an environment myself, Linux server (actually a NetApp filer hosts our repository now, but pserver still runs on the Linux box for NT clients) and NT, Linux and Solaris clients. As a startup, we could not afford a pricey, commercial VCS, and with what we do, CVS was a perfect fit (yes, I have used a number of different, "pricey" systems before). We are a fabless semiconductor firm, so we often have large, textual files (as well as small). CVS works very well for us, and is easy to administer once you get familiar with it. There is no issues with NT and UNIX clients, CVS handles them all of them from the server side, assuming you run CVS in pserver client/server mode (from at least for the NT clients).
Your sole documentation for CVS (other than the occassional Google search) will probably only need to be the Cederdqvist CVS Manual (here in HTML). If you aren't too familiar with CVS yet, you'll want to play around with a test repository while reading this manual for a month. Trust me, that is what I did the first time around.
In a nutshell, here are my recommendations for a CVS setup, with large files and a both NT and UNIX clients:
[ Note, there is a TkCVS client for UNIX, but it is _way_outta_date_. So don't use it except for possibly looking a work file status as well. In the case of both WinCVS and TkCVS, there is a _lot_ to be said about sticking with the CLI CVS client when checking in/out files -- I don't trust the GUIs to be flexible enough with anything but "browsing" the working files, but that's me. ]
[ Side note: If your setup and workflow is anything like mine (e.g., either NT or dual-boot NT/Linux on desktop, Solaris workstations in a lab), and an X-Server for NT is too expensive, you'll probably want to investiage Virtual Network Computing (VNC). VNC on a UNIX server (as compared to just using it as a simple pcAnywhere type setup on Windows servers, as most people do), is powerful. It is how we have ~10 different engineers running full GUIs on a single Solaris or Linux workstation, each with their own X-session (:1, :2, etc...). Then you simply connect from the Windows client and tada, a full X-session -- that even stays up when NT crashes! Or can be "shared" by Microsoft NetMeeting. Just thought I'd mention VNC since you probably have the same situation/setup I do. ]
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
BitKeeper is a CVS like utility, free for non commercial use, which provide some functionnalities besides the ones of CVS. The main one is the sub-repository which can be shared by a sub team and act as a buffer between private checked-out versions and the main repository.
Check out http://www.bitmover.com/bitkeeper/
It's hard to recommend one or the other without having more details about your requirements. For example, will the repositories need to be available in more than one location, how many projects, what kind of data, what kind of *usage*, how many users, how much resource the company is willing to expend, etc.
:)
For what it's worth, I'm currently responsible for the use of ClearCase in our division (not the installation etc., that's left to IT). (We/I'm trying to find someone to take over - I'm a developer, dammit!)
It does require more effort to set up initially, but once done it can be more or less left alone - a few hours a week is the most I've had to do to it in the last few months, IIRC. It's far more useful than CVS, at least IMO. I wouldn't want to try and switch us over, I don't think it would fly.
You can't escape their god-damned tools if you want to. It requires a full time IT staff to administer. You have to build an entire layer of tools on top for it to be usable. The benefits compared to simpler, lighter-weight solutions do not outweigh the disadvantages. I can't think of a piece of software I loath so much, with the possible exception of RealPlayer.
CVS is better otherwise (easier to administer, faster).
If you have a big team (i.e., you'll want exclusive checkouts to keep them from tripping over themselves) and/or a team in multiple locations (i.e., you'll need something like Multisite/Clearcase), you should go with Clearcase. Otherwise, give CVS a shot. If you don't like it, migrate to Clearcase later.
This sums it up nicely. For a big organisation, the initial cost is nothing compared to what you'll get in return. CVS doesn't scratch the surface compared to Clearcase but maybe you don't need all the extra features (a bit like Word! - although the extra features in Clearcase ARE useful).
I've used Clearcase for 3 years on a big project that involved 70-90 developers spread out over 4 sites (Rochester NY, Sydney Australia, Palo Alto CA, London England). We had a full time ClearCase administrator, and we needed it.
Right now I'm working on a much smaller development project, only 20 people in one office, and you just can't justify the expense of ClearCase for such a small project, so we're using CVS. Frankly, I'd rather have ClearCase.
My main objection to CVS versus ClearCase is that the support for branching in CVS sucks. Sure, you can branch, but every time somebody makes a change in the main branch, even in files you haven't touched in your branch, you have to merge the changes into your branch. In ClearCase, if you haven't modified a file in your branch, then you see the one in the main branch all the time, even if it changes. This means that unlike CVS, you don't have to run nightly cron jobs to keep merging everybody else's changes in area "A" of the code into your project that is only touching the code for area "B".
Besides that, the other thing I miss about ClearCase is the "-merge -xmerge" functionality for graphically resolving merge conflicts.
ClearCase's "winking" business I can do without on a small project like this. On the one where I was using ClearCase before, a full compile with no winking in took about 20 hours, so winking was a useful thing.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
I have to agree w/ folks who cite cost and support requirements as serious drawbacks to Clearcase. The per-seat licenses for Clearcase add up quickly. If your project spans domains, add the cost of additional Multisite licenses at a 1:1 ratio for each Clearcase license you own and you're talking buckets o' cash. Our company also has a full-time team of IT folks who do nothing more than support Clearcase - administering VOBs, writing trigger scripts, etc. So there's additional cost there, although I suspect there'd be a similar burden associated with CVS if you wanted to do anything really clever with it. That said, our project requires Clearcase for a couple reasons. The biggest? Most of our software organization has embedded it deeply in their processes. More sensibly? We have a team of people, all working on the same files simultaneously, so being able to manage multiple checkouts via branches is really useful. If we were working with hand-written C-code, I think I would find their merge and diff tools to be invaluable. As it is, we're using autocoders and graphical packages that decide to restructure the source files on a whim, making merges nearly impossible. Honestly though, if my downstream customers weren't committed to Clearcase, I probably could figure out how to get my work done w/ something like CVS. Bottom line? DO USE SOME SORT OF CONFIGURATION MANAGEMENT SOFTWARE! I can't imagine life without CM.
But it is so much more elegant than CVS if your use of version control is at all sophisticated! (Which, if your development effort is even medium size, I would argue it should be--this is stuff that pays off. But that is a separate discussion.)
For starters, there are some simple correctness issues. Clearcase tracks files across renames, which I gather CVS does not. Moreover, it versions directories, so if you look at an old view of the repository, you see the old names. This allows everything from corrections to badly chosen filenames, up to reorganization of the repository, without any fuss.
Clearcase also has a "findmerge" command with "common ancestor" support. This basically means, when it's time to merge, you always know exactly what you need to merge, with previous merges taken into account. I honestly don't know how you could live without this. (Note this is distinct the tool that actually performs merges, which is nothing special--I just use GNU diff3, myself.)
Second, clearcase has (to me) a killer feature, filesystem support. This means that that you get an ordinary-looking unix filesystem that automatically gives you the latest versions that you're interested in. Further, using an "extended" filename syntax, you can look at any version right from the filesystem. So if you want to see what's going on in the foo branch, you just vim code.c@@/main/foo/LATEST, or if you want to figure out which mainline versions use the fooble API, grep fooble code.c@@/main/*. This is addictive. NB: the filesystem support is not available in Linux :-(
Third, clearcase is very unix-friendly. While this is not a major difference with CVS, it is still worth pointing out (since many commercial products "don't get" unix). Most clearcase commands are close to their unix analogs (or in the same spirit, when there is no analog), and the documentation is in man pages. For me, this made learning clearcase easy, and adds a significant comfort factor.
To me, version control is not just about making sure I can work on my stuff without getting stepped on by anyone else. (CVS is fine for that.) It's also about expressing, understanding and managing the relationships between various versions and branches. This is a conceptually more difficult activity, and I frankly think many posters here don't see its value (it takes a while). But if you do, clearcase wins hands-down.
I admit that, while I have used CVS, I have only had day-to-day experience with clearcase (and Visual SourceSafe--bleh!), so I don't have a good sense of the "CVS routine". It perhaps includes some practices that mitigate the lacks I've cited. But, as long as someone else is taking care of the cost and administration and resources (under these circumstances, I have found clearcase reliable, if still a bit pokey), and I don't have to interoperate with outside developers who don't have clearcase, I would take clearcase in a second.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
somewhat offtopic but...
Subversion looks to be a promising, well thought out, version control system, incorporating the major features of CVS, but also adding and simplifying/clarifying/refining some features (directories can be versioned also, finally; merging and ancestry is also cleaned up and simplified).
http://subversion.tigris.org/
A detailed design doc describing the various layers, and example diagrams of branching and merging, and various other goodies is at:
http://subversion.tigris.org/svn-design.html
CVS is just barely good 'nuff...but it really feels incredibly hackish. I think it's about time there is a well thought out version control system, built from the ground up, independent of any legacy stuff like RCS.
It's 10 PM. Do you know if you're un-American?
I have never seen a source control tool as pathetic as VSS. But then again, I like CVS and prefer ClearCase, so your milage may vary.
I once worked at a place that migrated from Clearcase to Perforce because the former was just too damned expensive. I did lots of work with perforce, and I found it to be lightweight and easy to understand.... no filesystem access, but you get fancy merging like clearcase. Plus, there's a client for pretty much any platform you can think of. But you'll still need a dedicated admin for any installation of size.
See you, space cowboy...
I've used CVS, PVCS, VSS, (but not ClearCase), and Perforce is the best system I've ever used, bar none. Let me go through some of the key points:
- Quality of Support. I put this first becuase I think it's that important. I get same-day turnaround whenever I contact them and it's not a weekend (and I've gotten turnaround within an hour at 1am on sunday, so even then you often do), their tech support people know what they're doing and are willing to go the extra mile.
- The Model's Like CVS. I think this is actually important. To get all the "advantages" of clearcase, you have to be using the ClearCase file system, which basically means that your compiles are over NFS. Do you really want that? P4 gives you a local copy of all the files, just like CVS.
- Server Centric Model. While this can impose some difficulties for fully disconnected access, it saves your ass in a lot of places. Thinking of deleting a file and want to know if someone's working on it? You can see. Thinking of doing a branch and want to see the status of the branch on people's current machines? You can see. This can save you quite a few times.
- Multi-Platform Support Rocks. I've NEVER found a platform which P4 doesn't support. Mac, Win, Linux (we're using it on Intel and Alpha), Solaris, even IA-64 if you've got one, they run on everything. Very nice.
- Ease of Use. If you've got people who are familiar with ANY local-file based source control, they can be up to speed extremely quickly. I've got people who are familiar with CVS who are working extremely well in like 2 hours with P4, rather than weeks of training in CVS. So your training costs are virtually nil with P4 if your people already know CVS or VCC.
- Speed. It's FAST. REALLY fast. Because of the server-centric model, it's able to determine extremely easily what you need to download and what you don't. It uses things like MD5 digests to determine whether you're actually in sync, it uses its database of what you've stored, etc. And then it just downloads a compressed delta of the file and modifies it locally. If you've got people working over not-so-fast links, this will save your ass.
- It's TRANSACTIONAL. The basic unit of transactions is the Changelist. When you check stuff in, it's completely atomic. Either everything's submitted, or nothing is. That's it. So at any time you have, without labelling, a complete, transactional history of everyting that you've ever done, and it means that you can never download in inconsistent states. Everyone is consistent all the time. This also means that you don't have to constantly label everything, because the transaction ID acts as a unique identifier for the state of the database at any given point in time.
- Branching/Merging Rocks. I've never had a case where P4's branching/merging support didn't work perfectly. They detect three way merges, they detect multiple lines of integration/development, it all just WORKS. I can't stress how important this is for quality development, and it's infinitely better than the support in CVS.
- Ease of Administration. I administer 2 perforce servers. I spend, on average, about 2 minutes doing administration. The thing just works perfectly.
- Cheap Hardware. Unlike Clearcase, you can get a fairly cheap box for P4. We're running 25 users with about 70 clients on a $5k box (and most of that is RAM and RAID array), and it's so fast that most people never even notice, because its downloads are about as fast as a filecopy on the network.
- Stores in digested RCS files. So it gets around the corruption issue with some tweaking, but the core files are basically RCS files, which means that if you decide to give it the boot for whatever reason, you can integrate them into another source control system very easily. CVS will have the same issues with corruption that VSS does, because they dont' attempt to deal with the problems that RCS file corruption can incur.
I'm a little partial, but it's an amazing system that you really should evaluate. I think that if you're looking at CVS and ClearCase, P4 gives you the happy medium: faster and cheaper than ClearCase, more enterprise-friendly than CVS.In reference to your complaint about making changes in area A only, and having to keep merging because of changes made in another branch to area B --
If the two areas are really that distinct, so that you know your changes will compartmentalized, then you can solve this by making the two "areas" be CVS modules, which will keep their own separate branching history. So your code tree is made up of two modules, one on a main branch, the other on your private development branch.
If they are really extremely disconnected, then you might even keep them in different repositories.
If you use CVS or RCS to manage your source trees, moving to Perforce will not be that much of a stretch since your nightly build scripts will not need much tweaking (you do have nightly builds, don't you?). Indeed there is at least one CVS-style frontend to Perforce available from their website.
Perforce's big wins over CVS:
I am never going back to CVS, Perforce wins hands down (and, yes, it's available for Linux (and *BSD too)).
Technically, CC has one major advantage over the vast majority of CfgMgt tools: directories are just another element being managed.
There's a slew of minor cutes - such as winkin; decent branches; a workable multisite solution; very powerful triggers and the choice of dynamic or manually updated views.
There are a few technical downsides: on NT/W2K the registry use is opaque (very hard to do something non-standard w.r.t usage model); the API is proprietry (no 'use ClearCase;': I write lots of 'qx+cleartool...+')
Commerically, it has been reliable; it is feature rich; supports wizards and a CLI; well supported (good manuals and good technical support); and robust. There's a large user base with lots of experience which means that it is .
I didn't say it was cheap. But it's cheaper than a man-month of lost schedule.
It need not be difficult to maintain. There is an admin learning curve. (And the 'Rational U' exists for exactly this reason.) There is absolutly no excuse for "it lost all my data". (Is anyone seriously suggesting that you need't backup prior to letting a newbie install an unknown CfgMgt tool?)
Summary
If you want CfgMgt but don't want to spend cash, use RCS or write one.
If you have a commercial environment and a team of more than one person, then it is worthy of serious consideration.
Personally, I've been very happy with it.
CD.
-- Butlerian Jihad NOW!
I'm currently working on a big project for Air Trafic Control in France and we're using clearcase. VOB space resides on an enormous DEC Alpha-Server with plenty of RAM, plenty of disk and is accessed through a fast LAN. We compile and
link on separate hosts mounting the views with the
MVFS feature : a network filesystem crossed with a version controlling system. It's quite funny since you can access versionned files just like regular unix files but it can cost a lot !!!
Here are some performance measurements for a medium size file written in C...
1) clearcase view:
real 2m29.403s
user 0m10.630s
sys 0m25.653s
=> cpu = 36.283s / wait = 113.120s
2) Local partition:
real 0m13.522s
user 0m8.911s
sys 0m3.391s
=> cpu = 12.302s / wait = 1.220s
Running uptime on the VOB server and the compiling
host reveals that the compiling host is often idle, waiting for the overbusy server (cpu 100%) to complete VOB requests...
Be idle with clearcase !
Anarchy is about taking complete responsibility for yourself. - Alan Moore
I've seen a lot of good comments... only ones I really disagree with are the Clearcase haters. If you fully understand and use all the features Clearcase is one best code management and development systems I've ever used. Some comments about Clearcase I didn't see mentioned... it is very picky about the OS patch level. Because it is highly integrated into the OS filesystem, the support for new OS versions lags each version by a few months. Also I think things like CVS perform better in a WAN and dialin environment. Clearcase kind of assumes a fast network and a LAN. I've seem some robustness issues with CVS. Not that it is buggy per se, but because it keeps the client state on the local client filesystem (in the CVS/ directories) it can be corrupted and then it does strange things. Developers can do some pretty strange things in their local environment and they just expect CVS to figure it out... and CVS gets confused sometimes. I have a growing appreciation for Perforce (P4). It gives you everything CVS does, it is robust and does branching and merging to rival Clearcase. The "atomic" checkins of P4 is very nice over CVS and the reporting of checkin history and other info is a lot faster and better than CVS.
You might also take a look at ODE, the OSF Development Environment. Like CVS, it's layered on top of RCS. I beleive it has more support for branching than CVS.
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I'll qualify this from the start by saying that I haven't used Clearcase. I have used PVCS, MS-VSS, RCS and CVS and I have to say that in the propietary format for the repository's storage turns PVCS and MS-VSS into big the losers for the projects that I have run. Furthermore, setup of a MS-VSS repository on a project over this summer ate 2 weeks of my time which was critical since the project was on a 3 month long timeline. These two experiences really have me liking CVS since the organization of the repository is not proprietery and it's easy to setup and administer. I would remain openminded about clearcase but I would really see if there is a necessity to store all 10G of your project. From what other posters have said 10G is going to be a problem with cvs' pserver program. Ecks
The nice thing about the CVS checkout-less model is that the code hogs (you know, the guys who won't commit until Friday afternoon) get stuck with merging changes in if they wait too long and let their source get stale. This is nice because everyone else is free to grab the latest version, do a quick fix, and commit without hounding Mr. Code Hog to check it in.
One of the reasons that I became a lawyer was to avoid ever having to hire one. -SPYvSPY
Some have talked about wonderful "visual" merges. Frankly, if you're using branches that much and doing that much merging, you are over doing it. Merging branches is time-consuming and fraught with potential gotchas. I suggest finding a new development process that will avoid those problems (like XP). Anyway, you can visually access branches on CVS if you use a free client like WinCVS. It's great. Makes dealing with a CVS repo just like dealing with your file system.
Using ClearCase will likely lead you down a bad path of more complicated development processes. And that is a bad thing. Keep it simple.
The rest of Rational's toolset isn't much better. Our requirements people use Requisite Pro to store requirements. The development group is always asking them to see the requirements (duh!), but we don't have requisite pro, so we never seem to get them. They always say they can print out versions that we could see, but what they do print out or send us doesn't display right in Word or whatever, and usually they just can't be bothered to do the work necessary to output a format we can read. If they would just use a simple program, things would be so much easier...
They say developers are nuts for stupid toys - at least our stupid toys don't cost everyone time and money!
First, make it work, then make it right, then make it fast, then, make it bloated!
I used clearcase about 2 years ago in a large software project, 50+ developers, and it worked really well most of the time. The big problem is that you must have a trained clearcase admin that knows what they are doing. If they don't, it will break badly and often. (The worst mistake I've seen was when the VOBs were served off the same machine serving up user accounts. When the VOBs crashed the machine, all of /home went away...)
Clearcase's graphical tools, like the graphical merging tool, and the ability to see and compare branches and versions from within their gui is definitely a bonus.
The ability to merge clearcase with DDTS bug tracking was a definite pain in the ass. At least the way our CM management set it up. ("You mean I have to register and be assigned a software defect just to add a new feature???")
Managing labels can be a pain, especially when the nightly build breaks, and you need a new feature that was introduced in that build... Again, make sure your clearcase admin knows what they are doing or you could have a nightmare with the precedence that labels are searched to find "your" version)
I've just recently used CVS on a couple of small projects with just a handful (5) developers. The definite advantages are that almost anyone can maintain a CVS repository, and you still get some of the branching and merging features, but they seem to be a bit more crude than clearcase features. (Though clearcase can be pretty dumb with the auto merge. Have two developers add identical versions of the same function in two different locations in the same file, and it's happy to merge them both in without a peep.)
I've hit some weird snags with things like scripts that worked on Solaris, but broke on cygwin/NT because the binary flag didn't get set in CVS. I've also had directories that I couldn't remove from the CVS repository, and kept reappearing with every checkout. Probably just due to limited exposure to CVS so far...
Anyway, CVS's main advantages are the price, and its ease of maintainence. On the down side, support for gui interfaces to it don't seem to be standard across platforms. What gui you really like for linux probably doesn't exist for NT.
If you have the monetary and support resources to handle clearcase, it may be worth it. But if the price is just too scary, or your project just doesn't seem big enough to warrant it, then CVS is a good tool that should help meet your needs with a much smaller price tag.
What about stable release lines? Your team might have already started working on 2.0, but now you find a bug in 1.1. You expect all your customers to take an unstable 2.0 version? (and don't give me all this "always ready to ship" crap....if you don't have all the functionality ready, you're not ready to ship). You need to have multiple branches from there. Without good branch capabilities, you can't merge the fix in the 1.1 line with the 2.0 development.
So you're saying that you NEVER branch, and thus NEVER merge? How do you handle long-running projects? Projects with multiple releases? Projects with 100 developers?
I agree that complicated processes are bad. But processes should be there to help developers do their job. A good source control system with good branching and merging helps you when you need it.