I keep expecting customers to ask me “Is it contagious Doc?” Or state, “but I am an only child!!!!!” What am I referring to? Evil Twins!!! Sounds menacing right? It really is not, but to a first-time user or someone who has never encountered the warning, “Name already exists in backing stream,” it can be rather perplexing.
So what exactly is an Evil Twin you ask? It is a situation where two completely separate file elements in the same directory structure have the same name. It is actually a common problem across many software configuration management (SCM) systems. So how does this happen exactly? All it takes are two well intended individuals with their own workspaces. Lets use the following scenario, User A and User B both have their own workspaces attached to the same development stream. Currently we have the following directory structure;
\.\dir1\child_dir\
with the following files already under source control:
file_a.txt
file_b.txt
As part of our software project, we also need to create one additional file:
file_c.txt.
User_A creates and adds file_c.txt to source control in the child_dir directory and promotes this newly added file into the development stream.
At the same time, User_A was creating and adding file_c.txt, User_B did the exact same steps. However, A was first to promote so in effect User_A won the race. When User_B attempts to promote his/her file_c.txt the “Name already exists” error pops up front and center and does not allow the promote to continue. Evil Twin prevention at it’s best.
AccuRev tracks an element by its eid (element identification number) and not its name. This is how an Evil Twin is detected. When User_B attempts to promote File_c.txt AccuRev knows that there is already a File_c.txt in the development stream but notices that the eid’s do not match. They are truly separate files since they were independently created and added by different users. They are Evil Twins because they look identical but are different. Really only one of the two is Evil and that is typically the file that ends up getting removed/renamed. But that is another story for another day.
So what should an AccuRev customer do when encountering this problem? Give support@accurev.com a shout and title your email “Need Evil Twin resolution help” or “Name Already exists in backing stream error.” Or you may also take a look at the AccuRev Online FAQ’s in the Customer Support Forum.
Please feel free to let me know if this helps you out!
Stumble It!
Software Configuration Management 
You know what would be nice? If there was a status change to a twinned file so that you knew that you had an evil twin at a glance…
I see evil twins created more often by an exclude rule created by one developer and then another developer tries to add back in the ‘missing’ files since they didn’t know to check for the exclude rule.
What I’ve done in the past is to take the evil twin (i.e., the one that got there last) and do a “revert to backed”. Since the backing stream has no version of this file (remember, the file technically goes by the id and not only the name), it will go away, leaving the first version there. With that, you should have saved a version of the file which you just made disappear OUTSIDE OF ACCUREV. This will allow you to diff it against the true version of the file and merge the updates in. I have once written triggers to prevent this from happening, but the trigger was slow since it has to look for a file of the same name with a different ID in every level of stream between the workspace and the depot – which leads to a lot of server hits and slow downs. I thought accurev version 4.x was supposed to fix this, but apparently they did not.