Circular changeset dependency
Hi!
We had an interesting case here yesterday that a bunch of changesets seemed to depend on each other, so that we could only suspend all of them or none. The circumstances that lead to this state are not completely known, there were some merges going on and some other operations that remain in the mist.
At least I don't understand how changesets can gain this circular dependency when accepting them is so extremely strict concerning the cases when it can be applied as it is with RTC.
Can someone explain this to me?
Uli
We had an interesting case here yesterday that a bunch of changesets seemed to depend on each other, so that we could only suspend all of them or none. The circumstances that lead to this state are not completely known, there were some merges going on and some other operations that remain in the mist.
At least I don't understand how changesets can gain this circular dependency when accepting them is so extremely strict concerning the cases when it can be applied as it is with RTC.
Can someone explain this to me?
Uli
One answer
Here's a simple case involving only 3 change sets which illustrate when you can't suspend one particular change set out of the top 2, without suspending both of them.
We'll assume that we're starting at some change set called CS0.
Step 1: Modify fileA.txt --> Check-in to CS1 --> Complete CS1 --> suspend CS1 (CS1 states: 1 --> 2)
Step 2: Modify fileA.txt --> Check-in to CS2 --> Complete CS2 --> (CS2 states: 1 --> 3)
Step 3: Resume CS1 --> This results in a conflict and a new merges change set CS3 --> Choose "Resolve with Mine" (CS3 states: (1, 2) --> 3)
The order of the change sets in the history is now: CS0, CS2, CS1, CS3.
The merge graph looks like:
[CS3]
' \
' \
' |
[CS1] |
| |
| [CS2]
| /
| /
[CS0]
-Trying to suspend CS3 would result in a fork conflict since CS1 and CS3 have two different end states (This doesn't make sense in a history, so this is not allowed. Remember that CS3 was automatically created as a merge change set when accepting CS1 to resolve this).
-Trying to suspend CS1 cannot be done either as this would create a gap in history.
-You can however suspend CS3 and CS1 both at the same time, leaving only CS2.
We'll assume that we're starting at some change set called CS0.
Step 1: Modify fileA.txt --> Check-in to CS1 --> Complete CS1 --> suspend CS1 (CS1 states: 1 --> 2)
Step 2: Modify fileA.txt --> Check-in to CS2 --> Complete CS2 --> (CS2 states: 1 --> 3)
Step 3: Resume CS1 --> This results in a conflict and a new merges change set CS3 --> Choose "Resolve with Mine" (CS3 states: (1, 2) --> 3)
The order of the change sets in the history is now: CS0, CS2, CS1, CS3.
The merge graph looks like:
[CS3]
' \
' \
' |
[CS1] |
| |
| [CS2]
| /
| /
[CS0]
-Trying to suspend CS3 would result in a fork conflict since CS1 and CS3 have two different end states (This doesn't make sense in a history, so this is not allowed. Remember that CS3 was automatically created as a merge change set when accepting CS1 to resolve this).
-Trying to suspend CS1 cannot be done either as this would create a gap in history.
-You can however suspend CS3 and CS1 both at the same time, leaving only CS2.