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.

Comments

my experience...

[mperham]

I've used both in previous jobs for source code control. This is obviously different in that the files and projects are small (megabytes, not gigabytes).

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.

A rather sketchy testimonial

[A nonymous Coward]

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.

--

size info ?

[ndfa]

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!!!!

Working in such an env., 10GB+, NT/UNIX clients

[BitMan]

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:

1. Use a UNIX server, for both repository and pserver (client/server, runs on port 2401 by default, setup in /etc/inetd.conf) daemon (recommend both be on the same system, although there are exceptions to this rule). The UNIX CVS server is just so much more flexible, although our SV office uses CVS on NT (but they are NT-only on the client side). Since most Linux distros come with the latest CVS software, stick with Linux for your server (the CVS server/repository should always have the same or later version than any client).
2. If performance is important, make sure your server has a lot of memory if you run pserver (again, client/server daemon on server's port 2401). When you do, the server needs 1.2-1.5x the memory of the largest file checked in, otherwise, thrasing will occur as you swap pages to/from memory. Again, I _highly_recommend_ you run pserver for access from NT clients.
3. On the UNIX side of things, you don't have to use pserver. You can directly access the repository via NFS mounts. This is slower, but, for large files, you do not run into the thrasing issue on the server. In a nutshell, pserver puts all the burden (incl. memory usage) of the diff/commit on the server, whereas clients that access the repository directly do all the work. Even though you run pserver (for your NT clients), you can still access the repository directly on UNIX clients.
4. Do *NOT* checkout via NT to the same directory as via UNIX. E.g., if /home = \\server\home, do not try to checkout to /home via UNIX and then commit via NT from \\server\home, or vice-versa. The reason for this is that while the repository is OS-independent, the checked out working directories have OS-specific details (e.g., drive letters when checked out via NT, which the UNIX cvs client won't understand -- plus LF/CR issues where NT gets the later automatically added). Either adopt one of two philosophies (or both, depending on your user):
   • If you need to have working files accessable in the same place from both NT and UNIX (e.g., /home and \\server\home), then do all your cvs actions from the _UNIX_ side. The only issue you'll run into is any LF/CR that a Windows application would expect (since only LF will be used for line breaks since the working directory created/modified by UNIX). Since most of my Windows development tools don't mind LF-only breaks, I didn't have any problems with this.
   • The other philosophy involves a strict separation of working directories from NT and UNIX. Note, both clients still access the same, central repository and the same info. But when working, check out files via NT to a NT-only area and files via UNIX to a UNIX (possibly NT-also) area. This is what we also do with some people: Check out via NT to their local hard drive (which cuts down on network usage when they work), committing at the end of the day (for backup purposes), with other files being checked out to UNIX on the file server (and then accessable via both UNIX and, limited, NT over NFS/SMB shares -- which doesn't need to be committed at the end of the day since it gets backed up on the file server itself).
   • The use of each will depend on your workflow, possibly a per-user thing.
5. Be cautious about what you modify the CVS respository directly, but don't be shy to do it occassionally when you absolutely need to. This is what I love about CVS over other VC systems, a very understandable repository setup. Don't do it unless you cannot get a cvs client command to do what you want, don't do it reguarly and manually log anything you do to the repository for future reference. After a year and a half at my job, I have probably gone into the repository about 2-3 dozen times and haven't had any issues yet. Again, I haven't had such good luck with commercial systems and direct repository modification (when required).
6. Even if you are using a UNIX-only checkout environment, you can always use the nice, visual WinCVS client on the Windows side (provided you have a Samba share) to look at working file status (e.g., modified, current, etc...), but don't use to checkin/out UNIX working directories. If you are checking out via NT, then WinCVS will be a natural client choice. Just configure it for pserver, port 2401 and you'll be cooking.
   [ 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. ]
7. Don't forget to set some basic variables in all your user scripts (or in a global script called at login), e.g.:
   • CVSUMASK 007 -- just like a regular umask, only for cvs checkouts
   • CVSREAD 1 -- set if you want to force users to do a "cvs edit" before editing a file (great for keeping track of concurrent edits/development), unset (or don't set) if you don't.
   • CVS_SERVER server and CVS_PASSFILE $HOME/private/.cvspass -- if you use pserver (client/server) access (or unset/don't set if you don't).
   • CVSROOT /home/cmroot/cvsroot or CVSROOT :pserver:$USER@server:/home/cmroot/cvsroot -- the former for direct repository access by client, the later to use pserver.
8. Also get some basic aliases down for your UNIX clients, e.g.:
   • alias cvs '/usr/local/bin/cvs -d /home/cmroot/cvsroot' -- accesses CVS repository /home/cdroot/cvsroot directory
   • alias cvs '/usr/local/bin/cvs -d :pserver:$USER@server:/home/cmroot/cvsroot' -- accesses CVS respository on SERVER at /home/cmroot/cvsroot via pserver (client/server)
   • alias noncvs "cvs -n -q update -I '! CVS' -r HEAD" -- List all non-current or unknown files in working directory from repository (I use this all the time)
   • alias noncvsi "cvs -n -q update -r HEAD -- same as previous, except apply ignored file list (which are listed in file $CVSROOT/CVSROOT/cvsignore -- which you'll want to checkout and modify for your site).
9. Do *NOT* make your server public. CVS is NOT a secure server, unless you use something like Kerberos client/server (instead of pserver, on a different port, I've never done this), or pserver with SSH as the remove shell. If you are going to run a publicly accessable CVS server, you'll want to run in at least pserver mode using SSH or, in the worst case, pserver with different usernames/passwords directly in the CVS admin files (rather than using the default of the local UNIX accounts). I highly recommend _against_ running a server that is both internally and externally accessable. If you need to, setup two separate servers, with two separate CVS repositories and run a cronjob to update the external server on a regular basis. Better yet, get familiar with "cvs export" on automating the export of files from the CVS repository (withOUT working CVS info) to archives, external servers, etc...
10. Lastly, if you have not adopted Cygnus' Cygwin GNU environment as standard on your NT desktops, do it now. No need to pay others for UNIX tools on NT, Cygwin is all you need. Do it even if you don't use GCC, and do all your development via Visual Studio, etc... There are just too many good UNIX CLI tools to ignore in there and you'll wish you'd had them. A CVS client is included (or you can use WinCVS').

[ 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

pro ClearCase

[The Pim]

I'm surprised there are so few supporters of Clearcase here. Yes, it has two primary disadvantages: it is big, expensive, slow, bulky, and administor-intensive (I'm only counting that as one :-) ); and the repository is binary and opaque, accessible only via Clearcase commands.

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.

PLEASE consider perforce.

[MemRaven]

The Perforce Website

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.

XP is NOT a panacea

[MemRaven]

I'm sorry, but I've worked on XP projects. Once you get the project above 5-10 people, you can do XP, but you HAVE to do it in XP groups. In other words, you find a group of like 10 people, give them control over a subproject, and then give them their own branches.

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.