evil twin in RTC
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
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 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:
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.
Geoffrey Clemm,
|
|
Geoffrey Clemm (30.1k●3●30●35)
| 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
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.