Eben Eliason wrote: > I know GroupThink does everything it can to prevent collisions, but > with this we should also be thinking about the worst case. The > intended baseline behavior (before we get into any fancy merging > libraries) was to allow two instances with the same activity_id but > different version_ids to run simultaneously, and be joined by any of > their participants, thus allowing manual copy/paste merging. The > instance left open last would then become, naturally, the most recent > and therefore the "agreed upon" version moving forward.
Hmm. This creates a bit of a dilemma. In Groupthink, there is no such thing as a collision. You could say "collisions are not supported". Therefore, my model has been that different versions of a document should always be launched into a single shared session, where the data will be merged immediately and automatically. If the user wishes to create a separate branch not to be automatically merged with the existing document, she should create a copy of the journal entry with a new activity_id. (No, we don't seem to have a UI for that.) If the system is designed to prevent different versions from joining into a single shared session, then perhaps this explains the observed behavior. It also entirely prevents automerging of offline work. --Ben
signature.asc
Description: OpenPGP digital signature
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
