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)
Post preview certainly...
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
