Eben Eliason wrote: > Having said all that, it now seems clear to me that what I'm actually > concerned with is doing merges when v_x and v_y are the "most recent" > versions belonging to the individual who resumes them. No matter how > many new versions kids A and B make, a merge should be attempted > between their newest versions, but only their newest versions. ... > Do you agree > with my thought process here?
I think I understand what you're saying. From an interaction design standpoint, you're saying that if someone deliberately opened an old version, that's a good indication that they don't want the latest stuff, so the system shouldn't automatically connect them to the shared session and merge in everyone else's changes. I can't quite say I "agree". For example, I may have made some changes to the document, but decide I'd rather keep those changes local, and only merge back in with the group using some older version. Conversely, I may decide that I want to edit the latest version privately, even though there's a shared session going on, with the understanding that once I'm ready I'll be able to join and merge in. I think your suggestion is a good heuristic, but it would be nice to be able to override it. --Ben
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
