7.2 Planning for One or More Additional VOBs

The ClearCase LT server is initially set up with three VOBs: a UCM Project VOB, a VOB for use by the ClearCase LT Tutorial, and a VOB to hold source elements. Your organization must decide how to allocate data to additional VOBs on the ClearCase LT server. These are the principal trade-offs to consider:

• Splitting data into several small VOBs increases your flexibility. It is easy to move an entire VOB to another disk. It is more difficult to split a large VOB into several new VOBs and move one or more of them to another disk.

• Typically, you have fewer performance bottlenecks when you use several smaller VOBs rather than one very large VOB.

To users, a VOB appears to be a single directory tree. Thus, it makes sense to consider whether to organize your development artifacts into logically separate trees and create a VOB for each one. If two projects do not share source files, you may want to place the sources in different VOBs. Typically, several or all projects share some header (.h) files. You may want to assign these shared sources to their own VOB.

In your VOB planning, keep in mind that you can make several VOBs appear to be a single directory tree, using VOB symbolic links (Figure 4).

Figure 4 Linking Multiple VOBs into a Single Directory Tree

NOTE: Be sure that the text of a VOB symbolic link is a relative pathname, not a full or absolute pathname. For example, the following command creates a VOB symbolic link that makes the VOB \vob_lib appear as a subdirectory named lib in the VOB \vob_proj1:

cleartool ln -s ..\vob_lib lib (..\vob_lib, not \vob_lib)
Link created: "lib".

cleartool ls lib
lib --> ../lib

dir
...
12/18/94 10:23a <DIR> lib
...

Relative pathnames ensure that the link is traversed correctly in all view contexts. See the pathnames_ccase reference page for more on this topic.

Planning for Release VOBs

VOBs are not for source files only; you can also use them to store product releases (binaries, configuration files, bitmaps, and so on). Such VOBs tend to grow quickly; we recommend that in a multiple-architecture environment, you store releases for different platforms in separate VOBs.