evil twin in RTC
2 answers
In ClearCase, 99% of the time an evil twin was where a file was deleted in a directory version and then added-back by a user in a later directory version. It wasn't until version 7 or version 8 of ClearCase that they finally added a VOB-feature-level option to detect evil twins. Otherwise evil twins were introduced from users in parallel directory versions, either from another branch or different versions in the same branch (a user had an old unreserved checkout, added a file that another user already added in a reserved checkout later in the version tree, thus you now have evil twins.)
With RTC, it is mostly the same. If you delete a file in a changeset then add the file back in another changeset, it creates a versionable with a new UNID and a new history line, ignoring the previously deleted file. The other way is, again, parallel development: 2 users in different workspaces add the same file, possibly in 2 different streams, causing havoc later in the merges.
In ClearCase you solved this by doing an expensive version tree search on the parent directory to detect an evil twin, with out-of-the-box RTC you have nothing at the moment, as Geoffrey Clemm stated.
It would be nice if, like how ClearCase was later updated to detect evil twins, a new out-of-the-box precondition could be added to the Phase 2 server deliver (or a new Checkin hook) to check for this. The best would obviously be if IBM could put in a project-level setting to expend the additional server resources/time to do evil-twin detection on checkin and preserve the history lines.
Comments
In ClearCase, this sort of thing was VERY easy, the script was trivial. If it was someone adding a file that was removed in a previous directory version, it was trivial to create the new version and link to the old one. Otherwise you could block the action.
I believe this comment is saying that it is easier to write ClearCase triggers than it is to write RTC participants and advisers. That is probably true, and it is also true that ClearCase triggers were invoked on more operations than RTC. But it is also true that RTC participants and advisers provide a lot of functionality not provided by ClearCase triggers. For example:
- the ability to declaratively turn on/off triggers for selected project areas, based on role.
- the ability to provide a GUI extension to configure your trigger
- the ability to declare that your trigger is "advice", and can be superseded by a user with a given role
- the ability to automatically produce an explanation of why a trigger prevented you from performing a given operation.
Hi Geoff,
Geoffrey Clemm,
If someone actually were to write a Phase 2 Deliver (server) RTC precondition trigger to catch evil twins (maybe someone has, I haven't searched the forums for anything related to it) what would be the remediation workflow?
With ClearCase If I recall, the complete solution was to trigger on the preMkElem to check for a twin, and if found you'd hardlink the previous element into the current directory checkout version, checkout, then copy the contents of the original file and checkin. You'd also have to override the GUI context menu for 'Add to Source Control' so the mkelem didn't actually try to create it.
With RTC, even if you found a changeset had an evil twin, the changeset is already complete and immutable. I'm guessing the precondition would just not allow the deliver of the changeset. Is it then up to the user to A) discard the changeset, B) find the original changeset(s) that deleted the file causing the current twin issue, C) run a 'Patch' on the changeset to reverse the deletion to restore the file, D) re-do all the changes inside the new Patch changeset?