Source Code Control : Using ClearCase with LabVIEW

[danny_t]

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.

First a couple of basic things about ClearCase :

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

• VOB (Version Object Base)

  • 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

• View
  • A ClearCase View defines what version of of the elements in a VOB (both files and directories) that the user will see in the virtual file system. This is done by applying a set of rules which are stored in the Views configuration specification.
  • The configuration specification rules allow a large and powerful set of conditions to define what the user will see in the virtual file system. Rules can be set for the whole VOB or for individual files / directories. Rules can select by time, Labels applied to the VOB or most importantly using branches. For more information see  Controlling the contents of Views     Understanding Config Specs

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.

Typical Development Cycle & Best Practice

• Work should be carried out in changesets with a each changeset allocated it's own branch. 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

Why use changesets ?

• Consistent changes cause fewer build & integration problems
• Changesets are logically how people group what they do
• Changesets provide a natural link to change request management
• Changesets provide a natural link to project management
• Changesets streamline code reviews

• Create a new View to work on the new branch for this changeset.

• Work on Changeset.

• When the Changeset is complete and tested ensure a peer review of some kind is carried out on it before it is merged back into ther main code.

• Merge branch back into the main development line

• Apply a new Label to main development line.

• Lock the branch, destroy the view

LabVIEW Specific Tips

• To make life so much easier using LabVIEW with ClearCase or any other SCC toolkit, use LabVIEW 2010 or better & separate the source and compile code, this means that the new version of code created on your development branch will only be the files you have actually edited and not all the recompiled code that results from those changes. This in turn will make your Branch / changeset more managable  for peer reviews and merging. See VI Shots.

• To set-up LVCompare.exe to do LabVIEW diffs with ClearCase see LabVIEW wikki & Lava. With this setup you will be able to compare different versions of a VI from within a ClearCase Vtree or using the LabVIEW -> Tools -> Source Control _Show differences. As has been previously said by other, the LVcompare work best if you have one of the VI's you are comparing already open in memory.  In the Lava link above I have added a small wrapper so that when ClearCase calls the LVCompare.exe it first allows the users to select some of the copmare options.

• If you have a earlier version of LabVIEW and do not have LVCompare.exe, it is still possible to compare different versions of the same file in ClearCase. There exists a function vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi: that will do this for you, some good info on this can be found here. You can either write a wrapper around that function and get ClearCase to call that wrapper in a simliar way to the 'allow compare options' I mentioned above. Alternatively you can use the Openg 'compare to disc tool' with a nice little trick. Open up the VI you wish to compare, edit the View properties of your ClearCase View so that the version on disk is the version you want to compare against and just launch the compare to disk tool'. One note if you are using LabVIEW 8.2 or newer the default OpenG compare to disk does not work. You can find a working alternative here

• There is a ClearCase API package that I have created and released on LAVA to allow some ClearCase actions to be run programmatically within LabVIEW, for example checkin, checkout, get or set config specs, list all files on a branch, list private files in a view and more.  I would be grateful for any feedback from anyone who tried this package and feel free to suggest additional functions you would find useful.  Using this package you can do things like
  • Run the VI Analyzer automatically over all the files on a specified Branch.
  • Automatically add or change files within ClearCase as part of a build script.

• In Windows VOB's are mounted onto Network Drives using ClearCase views. You may well have more that one view into a VOB at the same time for example bug1_view  access path  -  F:\Project_A_VOB  & bug2_view access path  - F:\Project_A_VOB. It may well be that different member of the team always mount the same LabVIEW project on different drive letter due to perversity or maybe for a valid reason. It is a lot easier, and in the long run beneficial to write your LabVIEW in terms of a relative mount points for any pathnames used rather than use absolute pathnames and force everyone to us the same mount point.

• During the setup to integrate LabVIEW and ClearCase there is a required step that may well confuse people, well it confused me anyway. Having selected ClearCase as the Source Control Provider you are prompted to select a Source control Project Name and a Source control project path.  What is this path ? What do you do with this path if you later want to use a different view on a different path ? do you have to constantly change this setting ? Here is how to set this path and what not to do with it.
  • The path selected must be an absolute path into a mounted VOB in order for the LabVIEW - ClearCase integration to work e.g F:\Test_VOB1\project_A mounted through bug1_view
  • However once created, the LabVIEW - ClearCase integration will work correctly for ANY VOB mounted via any VIEW you do not need to change this path to work in G:\Test_VOB1\project_A or F:\Test_VOB2 \project_4. This does actually make sense if you understand how most ClearCase commands work.
  • If the path you originally provide is removed for example unmount the VOB Test_VOB1 or delete the view bug1_view. When you next launch LabVIEW it will hang on startup. It is common practice to remove old views and often we unmount views and remount them later at different access point. So this can be a real problem.
    • The solution for us to this was to create a fake view labview_int  permanently mount on drive Z:  that is only used for the purpose of the integration, no source control changes are done in this view.

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.

•Consistent changes cause fewer build & integration problems

•Changesets are logically how people group what they do

•Changesets provide a natural link to change request management

•Changesets provide a natural link to project management

•Changesets streamline code reviews