[Design] Interesting idea to avoid EIM conflicts

[Phillip J. Eby]

At 03:36 PM 2/14/2007 -0800, Jeffrey Harris wrote:
>Hi Phillip,
>
> > That sounds good, except that it's not really defined.  In the
> > edit/update case, I could email you a change Morgen made, along with a
> > change that I made previously (but Morgen's change is later, so my
> > lastModifiedBy says Morgen).
> >
> > Now, if one or both changes conflict with your Chandler, then what do we
> > do to your lastModifiedBy?  Under the model you propose, it is quite
> > possible to have a situation where, no matter what we do, the value will
> > be wrong!
>
>I don't follow why the value is wrong here.  The lastModifiedBy from the
>email would be Morgen, because his change was later.  If any changes
>don't conflict, the item changes to say Morgen changed it last.

If the conflicting change was by Morgen, then it will say Morgen changed 
it... when his changes haven't actually been applied.

If it's okay to do this, then it should be equally okay to say Morgen 
changed it, *regardless* of whether there were any conflicting changes.


>It's true that a particular change you made may look like it was made by
>Morgen, but I think Mimi's saying that's an acceptable failure mode for
>preview, so it's not wrong.

Right, but by the same logic, the case where we simply always update 
lastModifiedBy is never any *more* "wrong" than this... but is much simpler 
to implement and is easier to explain.

That is, the rule is simply "Morgen changed the item last," not, "This is 
who changed it last unless there's a pending conflict, in which case it 
might or might not be the person who changed it last."