wicke(a)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