RTC Ignord Element Gets Overwritten During Accept
We have users that want to have local changes in their RTC workspace that aren't overwritten with merges. Here is the scenario:
1. I am using RTC 6.0.
2. I make a change to a file in my local sandbox.
3. I mark the file that is in the Unresolved folder to ignore.
4. Another user makes a change to the same file and delivers the change, which ultimately shows up in my Incoming folder.
5. I accept the change from the other user.
6. Result is the changes from the other user get merged in with the version that is in my workspace (not my sandbox) and the my sandbox is overwritten with the results.
Problem is that the changes I made in step 2 are overwritten completely. They are lost.
The desired affect would be to prompt me and tell me I am about to accept something that has been ignored and therefore my local changes will be overwritten and give me the option to:
a. back out
b. delay the merge until later (put it in some other folder marked to be accepted at a later time)
c. back up the file.
d. Merge the incoming changes with my local changes. Not sure if this would be feasible.
Does anybody know how this problem can be avoided? If not, then I don't see the usefulness of the ignore feature unless you ignore elements that have never been checked into RTC.
One answer
The ignore feature is designed to be able to ignore files from ever being checked in, like object files or generated files.
https://jazz.net/library/article/126 is also a good article to understand the basic concepts.
If you have a file you are changing locally and you want to preserve, check it in. Before accepting you can decide to suspend the work or some work you are working on currently. This pulls the changes out of your repository workspace and keeps them. You can then accept the changes from the stream. You can resume your work later, which might require a merge.
Comments
Yes, the ignore functionality is a little tricky. You have to understand it completely. For example, if you ignore something globally like files ending in ".suo", and if prior to that some ".suo" files were checked in, the only way to remove them and deliver to the team is to remove the global rule first. Otherwise, deleting them from your sandbox won't show up in the Unresolved folder. I think it only makes sense to ignore a file that has never been checked in, otherwise ignore should be used with caution. Still, folks would like to have some functionality like ClearCase has hijacking. If you have a hijacked file and you merge something into it, ClearCase will let you keep your local hijacked changes anyways. For Jazz, I will recommend to developers to have a separate change set for 'local' changes and to suspend them every time they want to Accept.
Thanks for your input.