7.5 Creating a VOB

Follow these steps to plan and create each new VOB:

1. Log on to the ClearCase LT server. If possible, log on as a user who is a member of the same primary group as all other users who will need access to the VOB.

NOTE: The identity of the user who creates a VOB (user ID, primary group, and umask on UNIX; user ID and primary group on Windows) is used to initialize VOB access permissions. If a VOB is created by a user whose primary group is not the same as the primary group of other users who must access the VOB, you will need to edit the VOB's supplementary group list before those users can access VOB data. See also the protect and protectvob reference pages.

2. Choose a location for the VOB storage directory. You can use an existing server storage location, create a new server storage location, or use any other directory that has the proper characteristics for good VOB storage as described in Creating VOB Storage Locations.

• Choose a VOB-tag. A VOB-tag is a globally unique name by which all clients can refer to a VOB. A VOB-tag should indicate what the VOB contains or is used for. The tag must begin with a backslash or slash character and cannot include any spaces. Regardless of how a tag is created, ClearCase LT clients on UNIX will refer to the tag as /<tag>, while ClearCase LT clients on Windows will refer to it as \<tag>.

3. Create the VOB. This example explains how to create a VOB using the cleartool command line. You can also create VOBs using various GUI tools on UNIX or Windows.

The following command creates a VOB on Windows with the VOB-tag flex whose storage is in the directory shared as vobstore on a ClearCase LT server named pluto, and then returns location and ownership information about the newly created VOB.

cleartool mkvob -tag \flex \\pluto\vobstore\flex.vbs

Host-local path: c:\vobstore\flex.vbs
Global path: \\pluto\vobstore\flex.vbs

VOB ownership:
owner vobadm
group dvt

Whenever you create a VOB, you are prompted to enter a comment, which is stored in an event record (as the event "create versioned object base") in the new VOB's database.

To create a Unified Change Management Project VOB, which can store UCM objects such as baselines, projects, and streams, add the -ucmproject option when you run mkvob.

In many cases, the VOB-creation process is now complete. The following sections describe special cases and optional adjustments you may want to make to the new VOB.

Linking a VOB to an Administrative VOB

If you want a VOB to use global types defined in an administrative VOB, you must link the client VOB to the administrative VOB. On Windows, if you use the VOB Creation Wizard to create the VOB, you can specify the administrative VOB at the time of VOB creation. To link a VOB to an administrative VOB after you have created the client VOB, see Linking a Client VOB to an Administrative VOB.

Adjusting the VOB's Ownership Information

This section discusses changes that you may need to make to a new VOB's ownership information.

Access-control issues may arise when all prospective users of the VOB do not belong to the same group. (For detailed information on the topic of user identity and ClearCase access rights, see Chapter 3, Understanding ClearCase Access Controls.)

Case 1: One Group for All VOBs, Views, and Users

In organizations where all ClearCase users are members of the same group, all VOBs and views must also belong to the common group. A VOB or view belongs to the principal group of its creator and is fully accessible only to those users who are in the VOB creator's group.

The commands in Step #1-Step #3 here are sufficient to create a VOB in such a situation.

Case 2: Accommodating Multiple User Groups

If your organization has multiple user groups, there are special considerations when members of different groups share a VOB:

• Users can create an element only if their primary group is in the VOB's group list. If members of more than one group need to create elements, you must add the primary groups of all these users to the VOB's group list. Use the cleartool protectvob command.

• If members of more than one group need read access to an element, you must grant read access (and, for a directory, execute access) to others for that element. You must also grant read and execute access to others for all directories in the element's path, up to and including the VOB root directory. Use the cleartool protect command to change permissions for an element.

• Users cannot change an element (by checking out a version and checking in a new version), unless they belong to the element's group. The element's group does not have to be the user's primary group; it can be any group the user belongs to.

Note that to create an element, you must be able to check out the containing directory. Thus, a user can create an element only if both of the following are true:

• The user's primary group is in the VOB's group list.

• Any of the user's groups is the group of the containing directory.