wicke@wikidev.net:
On 07/16/2012 04:49 PM, Adam Wight wrote:
Cool! That's a nice solution because it's transparent to the end-user's system. However, if we use the current schema as you're describing, we would have to reconcile rev_id conflicts during the merge. This seems like a nasty problem if the merge is asynchronous, for example a batched changeset sent in email.
And that would be the core problem of asynchronous optimistic replication ;) Simple last-write-wins or union (for shopping carts..) strategies are still manageable, but merging textual changes is harder. Manual intervention will often be needed.
The editor rather than some unsuspecting reader should be best equipped to resolve these conflicts, so some degree of synchrony in the 'push' stage might make sense to provide an opportunity for editor-guided merging.
Gabriel
Although it might be simpler for the original editor to merge their own changes, that's not always what we want. The most flexible arrangement would be to separate the process into three workflows: edit, synchronize, and merge. Different people could perform each stage, or they can be folded together when appropriate.
On protected pages, for example, we specifically want some amount of peer review before deciding to merge. This could be seen as positive feedback also, if each successfully merged change comes with a bit of validation by the community.
Even a simple branching model will offer some delicious low-hanging fruit, for example, editors could "Save Draft" for any article and resume editing later.
-adam