...
If we consider the order in which the operations have occured, we can build the change lists :
- Case 1, tx < ty at tz :
- On server A, the list of operations is : rep(add, e1, t0), rep(del, e1, tx), add(e1/e2, ty)
- On server B, the list of operations is : add(e1, t0), del(e1, tx), rep(add, e1/e2, ty)
- On server C, the list of operations is : rep(add, e1, t0), rep(del, e1, tx), add(e1/e2, ty)
- Case 2, tx > ty at tz :
- On server A, the list of operations is : rep(add, e1, t0), add(e1/e2, ty), rep(del, e1, tx)
- On server B, the list of operations is : add(e1, t0), rep(add, e1/e2, ty), del(e1, tx)
- On server C, the list of operations is : rep(add, e1, t0), add(e1/e2, ty), rep(del, e1, tx)
- The problem is that we will have conflict if we apply the modifications when B reconnects to A and C. Typically :
- On server A and C : the rep(del, e1, tx) won't be accepted, as e1 has already a child
- On server B : the rep(add, e1/e2, ty) won't be accepted as the e1 entry does not exist anymore
Question : how do we handle this case ?