It's all about the answers!

Ask a question

What does an unresolved conflict of "Same Change Same Change" mean?

Stephen Evans (311) | asked Mar 22 '13, 5:34 a.m.
retagged Jun 25 '14, 3:19 p.m. by David Lafreniere (4.8k7)
We have some automation the performs code delivery from a workspace to one stream, then after some testing, delivers the same changes to a second stream. This automation is often handling different sets of changes concurrently but we have checks in place to ensure they are delivered in the correct order whenever there are common parts where the correct change history needs to be preserved i.e. no gaps.

We recently saw a situation whereby between delivery to the first stream and delivery to the second, an unresolved conflict appeared in a workspace for one of the outgoing files. This is odd since we restrict access to the streams so that only the automation is able to deliver and so nothing outside of our control should have been updating that stream. Alongside the file in the pending changes view appeared the following message:

(Same Change <-> Same Change) (Auto Resolvable)

It was indeed auto resolvable and the outgoing change remained as it was always expected to be i.e. no change to the existing outgoing change already present in the workspace. After resolving the conflict, a new 'merges' change set was created, containing that part, but the file name was greyed out.

We have seen the file name greyed out in the past when delivering a sequence of change sets for a part that have the net result of leaving the actual file contents unmodified. But we've never seen that "Same Change <-> Same Change" message before.

What is that telling us and what could have caused it?

Accepted answer

permanent link
Tim Mok (6.6k38) | answered Mar 27 '13, 2:24 p.m.
This occurs when the conflicting change sets have the exact same state. It has to be merged and shows up as grey because it was a no-op. It's just merging the change sets so that the history of the file is sane. This only happens with the same state. Two change sets that do the same changes to a file don't necessarily have the same state if they were created independently.

One way that this can happen is through duplication of workspaces. If you have a workspace with an active change set, the workspace can be duplicated with the option of keeping the change set open. This means the change set is duplicated as well. When the original change set and the duplicate meet in the same workspace, a conflict occurs but is marked as same change. It can be auto resolved and the merge is a no-op.
Stephen Evans selected this answer as the correct answer

Stephen Evans commented Apr 23 '13, 9:15 a.m.

Thanks for the explanation, which makes sense.

What I'm still a little puzzled about is where this second change set came from in my particular scenario. The workspace won't have been touched since the original change sets were completed and none of the incoming change sets contained the file in conflict (as far as I can remember).

Anyhow, we hadn't seen this scenario before and haven't seen it since so I'll just keep an eye on things. If it happens again, I'll try and track down the origin of the conflicting change.

Your answer

Register or to post 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.