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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
