Fixing problems with existing views after relocating elements

Although the relocate command creates symbolic links to preserve a VOB’s historical namespace, you might need to make additional adjustments after relocating elements so that existing views and tools can access them.

Cleanup guidelines

To clean up after Relocating elements to another VOB:
  • Use the view that was used for the relocate operation. When adjusting config specs, modifying build rules, and so on, use the same view (or a view with the same config spec), that you used when running relocate.

    In the source VOB, the relocate command completes its operation by checking in the parent directories of all relocated elements. Because this directory version does not include symbolic links to relocated elements, working in a view that selects this version allows you to discover which tools, build rules, or other processes will fail when they cannot access relocated elements.

  • Check important and historical views to see whether symbolic links work. As described in Problems with symbolic links to relocated elements, the inherent limitations of VOB symbolic links might make it necessary for you to modify the links or the config specs of views that reference them. Some kinds of config specs are more likely to have trouble:
    • Config specs with explicit pathname rules to relocated elements. (Config specs do not follow symbolic links to other VOBs.)
    • Config specs that use predominantly label-based rules. In this case, you might choose to add labels to relocated elements and their containing directories in the target VOB.
    • Config specs that look for relocated elements on a branch other than the one on which the relocate operation was performed. The relocate command creates symbolic links only for versions on the branch that was selected by the view in which it ran.
  • Fix broken views. After you find the problem config specs, use one of the techniques listed in Modifying old target directory versions to see relocated elements to make relocated elements visible again.
  • Recover any stranded view-private files. Run recoverview –sync on each view used to access the source VOB. Any stranded view-private files and DOs are moved to the view’s lost+found directory.
    Note: cleartool lsprivate lists stranded objects by their object IDs (OIDs).

Problems with symbolic links to relocated elements

VOB symbolic links provide a powerful mechanism for linking VOB objects, but they have some limitations that can affect views that access elements through the symbolic links left behind by relocate:
  • In general, cleartool commands do not traverse VOB symbolic links. Instead, they operate on the link objects themselves. For example:
    • You cannot check out a VOB symbolic link, even if it points to an element.
    • A describe command lists information about a VOB symbolic link object, not the object to which it points.
    • A mklabel –recurse command walks the entire subtree of a directory element, but it does not traverse any VOB symbolic links it encounters.
  • Config specs do not follow symbolic links to other VOBs.
  • Build scripts might include operations that fail on symbolic links.
  • If you move a relocated element with cleartool mv, any symbolic links to the element from the source VOB are broken.
  • Broken symbolic links—those with nonexistent targets—are not visible to most commands on Linux® or the UNIX system. This includes links that have accurate pathname information but point to elements not selected by the current view. The cleartool ls command lists these objects.
You can address these limitations in several ways:
  • Change the view’s config spec to reference elements at their actual pathnames in the new VOB. This is the most thorough and predictable approach. But it might not be practical when many elements have been relocated and the config spec needs rules that specify a large number of individual elements.
  • Add labels to relocated versions, and configure the view to select these elements with a label-based rule.
  • Apply a particular branch type to relocated elements, and configure the view to select this branch.