Overview This page describes what a sharing conflict is, the types of sharing conflicts and ways to mitigate such conflicts. We then describe proposals to resolve such conflicts.

A sharing conflict occurs when 2 or more people edit the same version of an item while unaware of the other's edits

Types of conflicts:

1. N people editing the same attribute(s) of the same version of an item
2. One person is editing while another deletes the same item
3. A removes B from ACL (or otherwise deprecates B's privileges) while B is editing
4. [anything else?]

Types of edits to attribute values

• Replace
• Add (Auto-merged?)
• Remove (Auto-merged?)

Tools to mitigate conflicts

• Use attribute-level granularity to distinguish conflicts
• Encourage users to use ItemConversations^? to prevent and resolve conflicts [InfD & Visual challenge]
• Workflow enforcement: Receive notifications and resolve conflicts before pushing out your own changes (for example, when user is offline and comes back online, external changes to the item are polled and resolved before pushing out any changes user made while offline)
• Use item versioning to avoid a whole set of conflicts.
  • For example, Anne, Barb and Carl are sharing an event (column 3 scenario). Anne changes the meeting location to "Pierre's". Barb sees Anne's change of location but still insists on changing the location to "Mandy's". So, Carl may get two change notifications of this event. This is not considered a conflict. In a p2p network architecture, Carl may even get the notifications out of sync (i.e. Barb's change before Anne's). This is fine because Carl's client knows that Barb made the modification after seeing Anne's modification, as Barb's Thus, Carl's client accepts "Mandy's" as the most recent location for the event.

Proposed solution for conflict resolution: Does ordering matter?*

All changes should contain the following information:

1. Version of the item that was changed
2. Change
3. Who changed it
4. When did they change it

That means, that at the very least, non-conflicting changes (changes committed to the same version of an item by different users) will show up in the right order.

There is concern that because computer clocks can often be wrong, that conflicting changes to the same version of an item will not arrive in the right time order.

But it is possible that they don't really need to show up in the exact time order they were committed. As far as the users are concerned, the conflicting changes were committed independently, so it doesn't really matter which one happened first.

At the very least, if the conflicts show up in the wrong order, they will show up in the wrong order for everybody sharing the item.

Strategically asynchronous syncing
To decrease the likelihood of conflicts arising at all, when users come online and sync, they should always "receive" changes before "sending out" their own changes. If Chandler detects a conflict, the user is presented with the opportunity to either

1. Replace their changes with the new changes OR
2. Send out their changes anyway (which means that they are now technically changing the newly received version, not the version they originally edited).

• Asynchronous_Sync.gif:
  

Worst-case scenario
Sharers edit the same version of an item and send out their changes before their proxy servers are able to receive changes. Sharers are notified of a conflict and given the option to resolve the conflict. Hopefully sharers won't simultaneously resolve the conflict in different ways over and over again. The item conversation should be the preferred way to resolve conflicts.

• Synchronous_Sync.gif:
  

Hierarchy of conflicts
How much information about the hierarchy of conflicts should we present to the user? We could present them with the complications of the entire version tree. Or we can simply hilight the conflict items. The sketch below illustrates an especially complicated exchange.

3 users: A B and C are sharing an item. Versions 1 and 2 are fine. Users A and B edit and simultaneously send out changes to v.2 creating conflicting versions 3a and 3b. They both receive notification of the conflict and attempt to resolve it differently, creating versions 4a and 4b. A glitch in delivery causes user C's edits of v.2 to arrive after users A and B have already exchanged versions 4a and 4b. At this point, users A and B appoint user C as the conflict resolver. User C creates v.5. Should v.5 be presented as a resolution of v. 4a, 4b and 3c? OR v.3a, 3b and 3c? On the right is a simpler visualization of the exchange.

• Hierarchy_of_conflicts.gif:
  

-- ChaoLam - 30 Jun 2004