ClearCase provided by IBM is an enterprise level Software Configuration Tool that is extensively used by bigger companies with large teams of software engineers.
ClearCase is not cheep and does rely on a good / reliable network infrastructure to function well. Also its real power and benefits arise from its superb Branching support. When using text based languages, where merging is an easy and everyday occurrence, ClearCase is at its best. I have worked on software systems with over 100+ software engineers working on the same product, controlling multiple versions of that product, some released versions and some under development. In this type of situation I would really not like to use any other tool.
However in the LabVIEW world, the large cost of ClearCase and its infrastructure requirements when coupled with the fact that LabVIEW is a language that does not merge well (yes I know you can do merges in LabVIEW, but it is quite a different and newer task than that of text merging) many people are using the newer and free SCC tools like Mecurial & SubVersion. These tools are ideally suited to smaller companies.
The type of sites that use ClearCase and LabVIEW together seem to be the bigger companies where ClearCase has already been in place prior to the introduction of LabVIEW.
I have used ClearCase for well over 15 years now, about 5 of them with LabVIEW. I also use Mercurial at home, I thought I would share some guidelines about using ClearCase & LabVIEW together as there does not seem to be a great deal of information around covering this.
In its standard mode, Dynamic ClearCase, unlike many other SCC tools ClearCase does not work on a repository / sandbox model. ClearCase uses a proprietary network file system called MVFS, with this system ClearCase mounts its source control database (VOBs) as a virtual file system though a dynamic view. Typically for a windows user this virtual file system is mounted as a windows network drive.
For example you may have a VOB called testTeam and under that VOB a folder called Project_A. You would create a view to access ClearCase and select an access path say drive F: Now when you mount the VOB your code will be available as F:\testTeam\project_A
a permanent data repository for a development tree or subtree. A VOB stores file system objects: directories, files, symbolic links, and hard links. (It also stores non-file-system information, meta-data
In ClearCase branch's are not only positively encouraged but embraced. The isolation of different developers work is done by branching. So two developers working on the same file is done by both developers working on different branches and then each merging the code back in a 'main branch' This is best understood by looking at some simple examples here & here.
changesets are a way to group a number of modifications that are relevant to each other in one atomic package, that may be cancelled or propagated as needed.