Repository View Merge Conflict Resolution

Scenarios

• Sharing
  • The current sharing proposal SharingProjectRepoView^? will lead to most sharing conflicts occurring within the sharing views, and not the main view
  • However, if sharing is asynchronous, the user could be modifying items during a sync, and when the main view commits, changes that came in from the remote server would have to be resolved in the main view

• ZaoBao^?
  • A background thread periodically adds RSSItems to the RSSChannels (possibly updating an existing item with new content)
  • If the user was able to modify that content a conflict could happen
  • Not likely to happen

• Mail
  • A background thread periodically fetches new MailMessage^? items (never updating an existing item, right?)
  • Since the background thread never modifies existing items, there is no chance of conflict

Strategies

In the case where a conflict does happen during a refresh of the main view, what is the strategy?

• Make sure a conflict never happens to begin with -- unlikely to be able to do this(?)
• Have each commit/refresh call wrapped in a try block which...
  • A) Uses a generic algorithm to resolve conflicts, like "always let the main view win"
  • B) Tries to resolve different Kinds with different algorithms (?)