Accepting incoming changes can overwrite unresolved changes

Hi Mark,

You have come upon one of the "Holy Grail" situations for RTC. (Holy Grail in this case meaning if they can solve this, it would be a big help to people using RTC). We also would like to see something that you are asking for. And, it is not just us. Others have reported this same type of situation. See RTC Work Item Defect 58899 for one. This Work Item is "Resolved" (for RTC v2.0) and the result is the current behavior you see now. There are a lot of good comments in it that explain this type of situation. By the way, if you type "overwrite unresolved" in a new query for RTC Work Items, you will get 36 results.

Mind you, this is not a complaint. I don't think that this is a "bug" and that it is working as designed. After all, you do get a warning about what is going on.

We handle this mostly by regularly "Checking in, but not Delivering" our code. This puts "Unresolved Changes" into a Change Set that will not be overwritten by any action. One of the RTC Work Items I found (maybe 58889?) mentions having a .jazzshed folder for files that get overwritten by load/accept actions. This just involves enabling a setting in the RTC preferences. Also mentioned is the ability to "find" lost code that was modified recently. We have done this in the past with good results (as long as we were looking right after "losing" the unresolved changes). These are all good "recovery" methods, but most developers I know aren't interested in recovering lost files, no matter how easy it is to so. They don't want to lose them in the first place.

So, after all that, I agree with you that we would like a better way to deal with a situation like this up front. The good news is that the Rational RTC development team is aware of this and they are working on it. However, it is not a trivial fix (as one would expect). We are working just fine with the way that they are handling it right now. We are currently using RTC v2.0.0.2 with iFix4.

Thanks,

-Walter

One of our people complained about this feature This is behavior borders on a bug. what do you think? Here is the setup

1. Modify and save some files in Eclipse
2. The user accepts an unrelated incoming change set, containing changes to the files modified in step 1
3. RTC produces a general warnings that there are unresolved change sets, do you wish to continue?
4. User clicks thru the warning and RTC overwrites the files, the users change is lost.

Suggested behavior:

Both RTC and Eclipse know which file are dirty. Why cant RTC take advantage of this and give more specific guidance to the user?
For example:

1. Modify and save some files in Eclipse
2. The user accepts an incoming change set containing changes to the files modified in step 1
3. RTC produces a Specific warning that files XYZ and ZUJ will overwritten if the change is accepted.
Perhaps RTC offers the user the opportunity to merge the offending items.
4. User resolves the changes or clicks thru the warning