[Chandler-dev] Handling email updates in a consistent way

[Brian Kirsch]

On Dec 4, 2006, at 10:11 PM, Philippe Bossut wrote:

> Hi,
>
> Jeffrey Harris wrote:
>> I wrote up a wiki page describing how we might use a date stamp and a
>> sequence number when managing email updates in Chandler, the link is:
>>
>> http://wiki.osafoundation.org/bin/view/Journal/MultiTransportSharing
>>
> I think the proposal (using sequence numbers) mitigates the most  
> probable issues. In a "normal" (fairly reactive) world, things  
> won't collide too often. However, as this is exemplified by anyone  
> using the Wiki (and being denied edit to a page), Bugzilla (and  
> experiencing "mid-air collision") or svn (and having to manual  
> handle merges), concurrent editing of items happens and can get  
> hairy...
>
> I mentioned a couple of systems here above because, clearly, this  
> problem has been dealt with in the past in multiple systems. I know  
> only of a couple of solutions:
> - lock edits: these are systems where you need a "ticket" to get  
> edit and block others while doing so (e.g. Wiki, RCS, SCCS): this  
> is not an option in Chandler since it would require the creation of  
> an email based protocol (yikes!) to get tickets...
> - concurrent access: these are systems that allow concurrent edits  
> being done and merge the edits (e.g. CVS, SVN), eventually handing  
> complex merges to the users when complex conflicts arise:  
> apparently we are also trying not to do that, relying solely on  
> sequencing and using a "most recent wins all" strategy (with the  
> added subtleties of using sequence numbers instead of dates and  
> dates if sequence numbers are equal).
>
> Clearly, we are betting that conflicts are going to be the  
> exception rather than the rule and that, when users will see their  
> edits wiped, they won't be too upset. Considering my experience  
> with the Wiki, I'm expecting we will have undesirable conflicts  
> more often than not. As Brian said during the meeting, we better  
> make sure that this caveat is well explained to users...
>
> Eventually, I think we will have to provide a real revision control  
> where:
> - merge will be done per attribute and, in the case of the note  
> field, use a smart paragraph merge
> - the whole history of changes will be browsable (so that users can  
> see their former edits)
> - the changes will be visually visible in the UI (different colors  
> for changed attributes or part of attributes, may be based on who  
> made the change as in Office revision control)
>

+1 Philippe. I don't see large scale adoption by users unless we have  
versioning and conflict resolution.
No one likes to lose local edits cause another user made a change to  
the item from a remote Chandler.

> Post preview certainly...

Yes, post-preview for sure!
>
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev