"What many have trouble with is not the required trigger that performs the 'insertion' or 'expansion' of the keywords during checkin, but rather the pain and added complexity it can cause for developer merges and deliveries if the trigger is not supported by an underlying 'keyword aware' type_manager." Some other SCM products (i.e. RCS) natively implement "keyword expansion" (also known as "keyword substitution") such that by viewing embedded data one can identify an item even after it has have left CM control and has been delivered to the field. This functionality does not exist in ClearCase as of version v2003.06, but can be easily implemented by creating a custom type manager and an associated. I say easy because how to do so is outlined in this document and the associated code is also included here. There are two (2) necessary steps to properly facilitate "keyword expansion" in ClearCase:
1) Create a pre-op checkin trigger that "expands/updates" the keywords in created source code. 2) Create a type_manager that ignores these keywords during ClearCase Compare and Merge functions.
The first step (the pre-op checkin trigger) is not too difficult and I have seen many such script that do the job, but they eventually fall out-of-favor with developers and are not used because they increase the complexity of merges and compares as often times only the keyword values themselves are changed in the file and for the ClearCase compare/merge facilities they are indistinguishable from developer changes and as such remove any possibility of a trivial merges during parallel development. You can use and modify the pre-op checkin trigger (KEYWORD_MGR.pl located in the "Triggers" of the ClearWeb Developer Network) we have provided or create your own. KEYWORD_MGR.pl is quite robust and is used in several organizations worldwide. The second step (the type_manager) is a bit harder to implement (but not for you since it is included) as it requires a more intimate knowledge of ClearCase. The key is to create a construct that traps all compare and merge functions in ClearCase and "swap" out the actual files to be used with equivalent files that have there keywords "suppressed" so that the keywords themselves are ignored in the comparison or merge. Files that are only different because of their keywords are in affect "identical" files to ClearCase. The type_manager (keyword_mgr.c) and installation instructions are available in the "Wrappers" section of the ClearWeb Developer Network. The result is to get "Keyword expansion/substitution" without adversely affecting developer merges and deliveries: For example, for two version of foo.c (version /main/int/4 and /main/int/fea/1) that both have the keywords:
/* $Author:$ $Date:$ $Revision:$ $Source:$ */
such that their complete file versions are depicted below:
| |
|
|
|
|
If you just have the trigger implemented the new versions have the correct embedded information in them, but in this case (and several others) the keywords changes themselves would not allow ClearCase to perform the "trivial" merge (which this would be if not for the keywords) from the "fea" branch to the "int" branch. Without the type_manager those keywords changes are treated as development changes for merges and compares. and developer will have to manually accept the conflicting changes. With type_manager enabled the keywords in the contributing versions (for compare or merge operations) are suppressed first so only actual development changes are evaluated resulting in the desired trivial merge which ClearCase can do itself.
| |
|
|
|
|
Once the merge is complete, checkin in the file creates a new version (/main/int/5) with the development changes as well as the new expanded keyword data which is automatically expanded with the pre_checkin trigger KEYWORD_MGR.pl.
|
|
