Using checkvob to find and fix problems with global types

checkvob can find and often fix many problems that occur in an administrative VOB hierarchy.

1. Run checkvob –global in any VOB in the hierarchy.
   If checkvob detects that the VOB has more than one AdminVOB hyperlink, it stops and prompts you to correct the problem.
2. To correct the problem, use cleartool describe –long to list VOB hyperlinks, and then use rmhlink to remove all but one of them.
   In this example, the VOB \sources has two AdminVOB hyperlinks, one of which must be removed before checkvob can continue checking the hierarchy.

   cleartool describe –long vob:\sources
   versioned object base "\sources"
   ...
     Hyperlinks:
       AdminVOB@2@\sources -> vob:\projects
       AdminVOB@3@\sources -> vob:\admin1
   cleartool rmhlink AdminVOB@3@\sources
   Removed hyperlink "AdminVOB@3@\sources".

3. After the hierarchy has been corrected, run checkvob –global again to check for problems with global types in the hierarchy.
   checkvob can detect the following types of problems:

   • Eclipsing local types
   • Eclipsing local locks
   • Protection mismatches
   • Name mismatches
4. Review the log file, and then run checkvob –global –fix to correct any problems.
   With the –fix option, checkvob does the following:

   • Changes the name of each local copy to match the name of its global type.
   • Attempts to acquire eclipsing local copies and eclipsing ordinary types. If a type being acquired is locked, the locks are discarded the global type is locked. If the global type is not locked, the lock information from the first acquired type is applied to the global type.
   • Changes ownership of each local copy to match the ownership of its global type.

   Unless you specify –force, checkvob prompts you before attempting to fix any problems it detects.