8.3 Working with Administrative VOBs

The following sections describe how to work with administrative VOBs.

Creating an Administrative VOB

To create an administrative VOB, follow the procedures described in Creating a VOB.

NOTE: An administrative VOB can also store elements.

To put a VOB into use as an administrative VOB:

1. Link client VOBs to it. See Linking a Client VOB to an Administrative VOB.

2. Create global types in it. See Creating a Global Type.

Linking a Client VOB to an Administrative VOB

To associate a client VOB with an administrative VOB, create a hyperlink of type AdminVOB from the client VOB to the administrative VOB.

cleartool mkhlink -c "link to admin VOB" AdminVOB vob:\dev vob:\admin_dev
Created hyperlink "AdminVOB@40@\dev".

Administrative VOB Hierarchies

A client VOB can have only one administrative VOB. However, you can create administrative VOB hierarchies, in which a client VOB is linked to an administrative VOB, which is linked to another administrative VOB. (Circular relationships are prohibited.) For example, you can create an administrative VOB that contains global types used by all VOBs at your site, plus two other administrative VOBs, each containing global types specific to the needs of particular teams. Figure 7 illustrates this example.

Figure 7 Administrative VOB Hierarchy

You can add an administrative VOB to the middle of a hierarchy by removing an existing AdminVOB hyperlink and adding two new ones. This operation does not disrupt existing type definitions, because the hyperlink between a local copy and its associated global type remains intact.

To add an administrative VOB to a hierarchy:

1. Remove the AdminVOB hyperlink at the point where you want to add the new administrative VOB. For example, if you want to add an administrative VOB between \admin and \admin_re:

cleartool describe -l vob:\admin
...
Hyperlinks:
AdminVOB@40@\admin_re <- vob:\admin_re

cleartool rmhlink -c "insert admin VOB" AdminVOB@40@\admin_re
Removed hyperlink "AdminVOB@40@\admin_re"

2. Create the new administrative VOB.

3. Associate the new administrative VOB with its higher level administrative VOB. For example, if the new administrative VOB is \admin_lb:

cleartool mkhlink -c "link admin_lb to admin" AdminVOB vob:\admin_lb vob:\admin
Created hyperlink "AdminVOB@40@\admin_lb".

4. Associate the client VOB with the new administrative VOB.

cleartool mkhlink -c "link re to admin_lb" AdminVOB vob:\re vob:\admin_lb
Created hyperlink "AdminVOB@40@\re".

Listing an AdminVOB Hyperlink

Use the ClearCase Administration Console or the cleartool describe command. The describe command shows the hyperlink that associates a client VOB with an administrative VOB. The hyperlink always points from the client VOB to the administrative VOB. The following examples show AdminVOB hyperlinks.

• Client VOB \dev, whose administrative VOB is \admin_dev

cleartool describe vob:\dev
versioned object base "\dev"
...
Hyperlinks:
AdminVOB -> vob:\admin_dev

• Administrative VOB \admin with two client VOBs

cleartool describe vob:\admin
versioned object base "\admin"
...
Hyperlinks:
AdminVOB <- vob:\admin_dev
AdminVOB <- vob:\admin_re

• A VOB that is both a client VOB and an administrative VOB

cleartool describe vob:\admin_dev
versioned object base "\admin_dev"
...
Hyperlinks:
AdminVOB -> vob:\admin
AdminVOB <- vob:\dev

To display the hyperlink ID, use describe -long. The hyperlink ID includes the VOB-tag of the VOB in which the hyperlink was created. For example:

cleartool describe -long vob:\admin_dev
...
Hyperlinks:
AdminVOB@40@\admin_dev -> vob:\admin
AdminVOB@40@\dev <- vob:\dev

Restrictions on Administrative and Client VOBs

The following restrictions apply to administrative and client VOBs:

• If you try to link a client VOB to an administrative VOB and any global type definitions in the administrative VOB would be eclipsed by ordinary types in the client VOB, the operation fails unless the -acquire option has been used. See the mkhlink reference page for more information.

• A VOB can have only one AdminVOB hyperlink pointing from a client VOB to an administrative VOB. The mkhlink command prevents the creation of a second AdminVOB hyperlink to any administrative VOB.

If an Administrative VOB Becomes Unavailable

If an administrative VOB becomes unavailable to a client VOB for any reason, attempts at the client VOB to create instances based on a now-inaccessible global type definition produce the following error:

cleartool: Error: Unable to access administrative VOB "adminVOB" of clientVOB

In addition, the output of cleartool describe for the client VOB may not show the administrative VOB.

Breaking a Link Between a Client VOB and an Administrative VOB

You can convert a client VOB to a regular VOB by removing the AdminVOB hyperlink and all GlobalDefinition hyperlinks between the client VOB and its administrative VOB. You must remove all such hyperlinks to sever the connection between a VOB and its administrative VOB. The following sections describe how to remove the hyperlinks using the command line. You can also use the ClearCase Administration Console.

Removing the AdminVOB Hyperlink

To remove the AdminVOB hyperlink between the client VOB and the administrative VOB:

1. Determine the name and ID of the AdminVOB hyperlink:

cleartool describe vob:\dev
versioned object base "\dev"
...
Hyperlinks:
AdminVOB@40@\dev -> vob:\admin_dev

2. Remove the hyperlink with the rmhlink command:

cleartool rmhlink AdminVOB@40@\dev
Removed hyperlink "AdminVOB@40@\dev".

Removing All GlobalDefinition Hyperlinks

To remove all GlobalDefinition hyperlinks that connect local copies in the client VOB to global types in the administrative VOB:

1. Determine the names of all local copies:

cleartool lstype -local -fmt "%n\t%[type_scope]p\n" -kind attype -invob \dev
Tested local copy
Feature Level ordinary
...

cleartool lstype -local -fmt "%n\t%[type_scope]p\n" -kind brtype -invob \dev
...

cleartool lstype -local -fmt "%n\t%[type_scope]p\n" -kind eltype -invob \dev
...

cleartool lstype -local -fmt "%n\t%[type_scope]p\n" -kind hltype -invob \dev
...

cleartool lstype -local -fmt "%n\t%[type_scope]p\n" -kind lbtype -invob \dev
...

2. For each local copy, determine the name and ID of the hyperlink linking the local copy to its global type. For example:

cleartool describe -local -long -ahlink GlobalDefinition attype:Tested
Tested
Hyperlinks:
GlobalDefinition@58@\dev -> attype:Tested@\admin_dev

3. Remove each hyperlink with the rmhlink command:

cleartool rmhlink GlobalDefinition@58@\dev
Removed hyperlink "GlobalDefinition@58@\dev".

Removing an Administrative VOB

Remove an administrative VOB with the rmvob command or by using the ClearCase Administration Console. When you remove an administrative VOB:

• All AdminVOB hyperlinks connecting to the deleted VOB are removed.

• All GlobalDefinition hyperlinks connecting to global types in the deleted VOB are removed.

• All local copies in the deleted VOB's client VOBs are converted to ordinary types.

Fixing Global Type Problems After Restoring a VOB from Backup

Any time you restore an administrative VOB or any of its clients from backup, there is the possibility of a mismatch in global type information (AdminVOB hyperlinks) if the VOBs were backed up on different schedules. For example, if an administrative VOB is backed up before a new global type is created, its client VOBs will not be able to use instances of the new global type after that backup is restored. To prevent problems caused by this type of mismatch:

• After you restore an administrative VOB from backup, you should check for and fix any broken hyperlinks in that VOB and all of its client VOBs.

• After you restore a client VOB from backup, you must check for and clean up any broken hyperlinks from that VOB to its administrative VOB.

To remove broken hyperlinks, use checkvob -hlink. For more information, see Checking Hyperlinks and the checkvob reference page.