It's all about the answers!

Ask a question

evil twin in RTC


Sreedhara thirthahalli (591315) | asked Sep 09 '14, 10:35 p.m.

Hi

I would like to know in RTC about Evil twin? How to avoid them?

in clearcase we have something called evil twin?

Is there any trigger? will RTC supports trigger like clearcase?

2 answers



permanent link
Winston Enos (33116) | answered Sep 10 '14, 1:43 p.m.
Sreedhara thirthahalli,

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
N Z commented Sep 10 '14, 7:44 p.m. | edited Sep 10 '14, 8:31 p.m.

 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.


Unfortunately, it's not so simple in RTC, nor so powerful. There are participants and advisers, and many users on the forum are doing all sorts of interesting things. As for myself, I think it is a very poor design and solution and for various reasons will only ever resort to doing something like this as a last resort (fortunately, my colleagues feel the same way).

So, if it's absolutely essential, that's the path you'll have to take. There must be other users in the forum who have already implemented something like this and may be will to share.


Geoffrey Clemm commented Sep 10 '14, 8:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.


N Z commented Sep 11 '14, 12:03 a.m.

Hi Geoff,


Well, you may be right, I don't claim to be an expert, I only have enough information to know that this is an area, in my opinion that should be avoided. I respect that other forum members have different views and have been doing some interesting stuff. For a number of reasons, we in our organisation have steered well clear of this path.

We are probably talking a different language, but my understanding of the examples you have given is that all of them, except the 2nd could be achieved fairly simply in ClearCase too. Of course, ClearCase wasn't perfect, there were no true server triggers (as RTC has), with the introduction of web views the whole trigger structure fell apart.


Winston Enos commented Sep 11 '14, 9:51 a.m.

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?


permanent link
Geoffrey Clemm (30.1k23035) | answered Sep 10 '14, 1:03 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
RTC supports process pre-conditions and follow-up-actions on certain operations, which are like ClearCase triggers.  You can define actions on "deliver", but cannot define actions on checkin.   So you would only be able to catch this issue at "deliver" time, and you would have to write your own custom pre-condition to do so.

Your answer


Register or to post your answer.