14.3 Before Relocating Elements

Take the following steps before moving elements from one VOB to another:

1. Inform users of your intentions. The affected source and target VOB elements must be inactive during the relocate operation.

2. Check for views with checkouts in the VOB. Use the ClearCase Administration Console's VOBs node. This node has a Referenced Views subnode that lists all views with checkouts in the VOB and allows you to manage these objects from the console window. You can also use the cleartool lscheckout command to list checkouts on a per-view basis.

3. Resolve any checkouts. Resolving checkouts typically involves notifying the appropriate users about the problem. relocate aborts if it encounters an active checkout in any directory it is trying to move.

4. Establish a working view. Use a working view whose config spec selects the branch (typically \main) on which the move is to occur.

This step is very important. Your view must be able to see and check out elements in both the source and destination VOBs. Therefore, a working view configured without a CHECKEDOUT rule, for example, is inappropriate. Also, run relocate with the same view or with the same config spec that you will use to adjust makefiles, rebuild libraries, reset config specs, modify development tools, or complete any other work that may accompany the relocate task. See also After Relocating Elements.

5. Run relocate in test mode. Run the intended relocate command and monitor its output, but stop short of moving any elements by responding no at this prompt:

Do you want to relocate these objects? [no]

You may want to include the -qall option in your test run, to examine relocate's potential handling of borderline elements:

cleartool relocate -qall dir1 \new

When relocate encounters a borderline element, its output looks like this:

Element "f3" is
located outside the selection tree as "f3" in
directory "\bigdir\dir2",
located inside the selection tree as "f3" in
directory "\bigdir\dir1".
Do you want to relocate it? [no]