Base ClearCase FAQ: 1.2.8 What is an evil twin?

For reasons essentially bound to the management of a world under evolution, there cannot be full agreement on terminology.
A couple of opinions, starting with the narrowest one (which some might find the only pragmatic one):

• An evil twin is any of two links with the same name, each pointing to a different element, in two different versions of the same directory element.
• A duplication of content, such as it escapes manageability from the tool—this is undoubtly more abstract, and extends from twins to siblings, cousins, and further, but allows to spot the same evil in a wider scope.

First acception, first opinion

The reason they are evil is because they create the appearance of a directory containing the same file on two different branches, when in fact they contain two different elements with the same name. If this situation isn't detected, then one can very well end up with two change histories of something that everybody thought of being the same file, only to get a rude surprise at merge time. There is essentially no good way to merge the two change histories.

Evil twins get created when two developers concurrently add the same file to source control without coordination, or if one developer copies files from another developer's view and puts those files under source control.

Copying files around should be discouraged, but the best way to avoid evil twins is to create a pre-mkelem trigger that will search through some or all versions of the directory containing the new element, verifying that no link with the same name exists.

The following perl code implements this trigger and prints out a warning together with the suggested link command that will link the existing element into the version of the directory where the newly created element would have ended up.

The trigger will also do a sanity check on the file name itself, catching most unintentional element creation attempts.

The trigger relies on the excellent ClearCase::ClearPrompt and ClearCase::Argv modules, available at a CPAN site near you.

Eviltwintrigger

Critique in the context of the second acception

• It is always possible to create evil twins, and triggers won't protect you from evil.
• The fact that the two files bear the same name in the same directory is not essential, apart from the point of view of the trigger.
• It could be two elements with the same name under evil twins of the directory; or files with the same name in different directories (the hierarchy may change, the names may change,...)
• It can be elements which were intentionally created with different names, although could have been versions of the same element, such as when naively importing tools from a flat file system namespace into ClearCase, with hardcoded version extended names.
• It may be some information duplicated in different files, with different grain, so that the conflict is completely beyond the reach of the SCM tool.
• With evil twins at large, you never know exactly what your trigger should be looking for, or where.
• If derived objects are your first concern, evil twins may be identical DOs created when winkin could have shared the older one (e.g. because of promoting unshareable DOs, or because of viral propagation from an initial case, through depended upon DOs—maybe the oldest never fixed ClearCase bug, reported by Doug Robinson more than 10 years ago)
• See the comments at the end of 1.7.1.

[Note: I extracted this page, and from it the perl trigger above, from the BasicClearCase page, in order to make corrections to it in a manageable way -- MarcGirod - 02 Sep 2007]