What does an unresolved conflict of "Same Change Same Change" mean?
Stephen Evans (3●1●1)
| asked Mar 22 '13, 5:34 a.m.
retagged Jun 25 '14, 3:19 p.m. by David Lafreniere (4.8k●7)
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?
|
