Conflict changeset differences seem backwards after a merge

Adam Elliott (13●2●4) | asked Jan 10 '13, 11:15 a.m.

We had a stream for development, and at some point in time branched it off into the current development stream for the next version. The older stream remained for a few final fixes, then another stream was created off of it for maintenance.

Now a bunch of development work has happened in the meanwhile, and a few maintenance fixes, and we want to merge some of these maint fixes into development. So I find a changeset, right-click, and apply to my workspace off the current dev stream. Let's say there's a merge conflict that is auto-resolved. The resulting "Merges" changeset seems non-intuitive... when I view the differences in eclipse, I'm seeing all changes on the development stream as if they were applied on top of the single maintenance change. I was expecting to see the difference with respect to the dev stream (so the changes from the maintenance fix applied on top of the existing development code).

If I view history of the file within the workspace I can get the info I want by explicitly comparing the new Merges changeset with the previous one from the dev stream.

My question then is why does the "Merges" diff contain all the development changes rather than the incoming maintenance change? Is this a side-effect of how streams were created, or is this just the way merges always work?

Thanks.

Accepted answer

permanent link

Tim Mok (6.6k●3●8) | answered Jan 10 '13, 3:31 p.m.
JAZZ DEVELOPER

This is a matter of the order that things happened. Your workspace already had the current development change sets. When you accepted the maintenance, the history order changed. If you look at the file history, what is the order of the change sets?

Do you see something like this where the bottom is the oldest change set:

merges
maintenance
current

If so, your attempt to open a compare on the merges change, does a compare with previous. Since the previous is the maintenance, the difference is the change from the current change set.

I would say it's just how merges work but it's more about the context of where you're opening the compare and what the compare action thinks you want to see. It's only comparing against previous and not taking into consideration that your perspective is thinking of a compare of what's already in your workspace to what you just accepted. Maybe it should always compare to the ancestor version and not the previous in history but I think it would be confusing to other users that always expect the compare action to be against the previous change set that they see in the history view.

Adam Elliott selected this answer as the correct answer

Comments

Adam Elliott commented Jan 11 '13, 1:42 p.m.

Yes, that's the order the changes appear in the history. I suppose this behavior would be more useful if I were accepting changes into a local workspace where I'm familiar with all the local changes but not necessarily what's incoming.

Anyway, thanks for your response. Good to know we're not just messing up our stream configuration at least.

It's all about the answers!

Related questions

Conflict changeset differences seem backwards after a merge

Accepted answer

Your answer