Evil Twins

EVIL TWINS

Evil twins is a commonly used phrase to describe a situation in which two
Elements, of the same name, are created in two different versions of the same directory element.

Evil twins are often created when two people add the same file to source control at the same time.clearcase allows this to happen because the element is actually referenced internally by its object id(OID) and not its name.

Ex:
DIR1@@/main/1 = => foo.c added
DIR1@@/main/2 = => foo.c rmnamed
DIR1@@/main/3 = => foo.c added

We can use cleartool find command to locate either FILE or DIRECTORY elements that may be evil twins.

1.when two files are found with the same name in two different versions of the directory, we can run the cleartool dump command to see if the files are in fact different elements.

Ex: foo.c ==> DIR1@@/main/1 foo.c ==> DIR1@@/main/3

If we suspect foo.c may have an evil twin, run the cleartool dump command for each file to obtain the object identifier (OID).

It is important to address evil twins in our configuration as soon as possible after discovering them,we have two ways to resolve the problem.

1. Rename one of the elements using the cleartool mv command.
2. Remove one of the elements using the cleartool rmelem command.

The best solution to control the creation of evil twins is to implement a pre-operational trigger during the mkelem/ add to source control operation.

The objective of the trigger would be to search the directory version tree for an element of the same name prior to creation of the new element.

The script used by the trigger will be required to look for two different files, with the same name, in two or more different versions of the same directory.

ECLIPSED FILES

CLEAR CASE ECLIPSE:

A VOB object that is not visible because another object with the same name is currently selected by the view.

The objects that become eclipsed most frequently are elements. An eclipsed element is created when it is obscured by a view-private file.

An eclipsed element is seen only in dynamic views. It’s basically when a view-private file/directory has the same name as an element in that same directory.

This event may occur when the dynamic view is not able to delete the local copy of the file after we have checked it in.

Views always display view-private items first. It often occurs when one or more developers are working in the same area adding new features to them.

An eclipsed file will be listed in a GUI window with a partially shadowed moon icon

The solution for resolving eclipsed objects is to rename or remove the local / view-private copy of the object that is obscuring the VOB copy.

WHAT IS “CHECKED OUT BUT REMOVED”

One of the most common error messages in ClearCase is when an element (file or directory) is "checked out but removed". From some graphical user interfaces (GUIs), the element even appears to be missing from the directory where the element is suppose to be located.

By executing "cleartool ls" from the command line, the element appears to exist yet removed.

For example:

$ clearcasetool ls is the command given and the output maybe

test.txt@@/main/CHECKEDOUT from /main/2[checkedout but removed]

This problem occurs if an element has been checked out and the checked out object is then deleted using Windows or UNIX/Linux commands (such as delete/rm or rmdir,). It is the reverse of the eclipsed file case.

The solution to this problem is to un-checkout the file or directory.