On Thu, Jan 23, 2014 at 9:22 AM, Matthew Flaschen
On 01/22/2014 12:35 PM, Petr Bena wrote:
this explanation should be in the documentation
anyway I guess I need to use both of them?
basetimestamp (the timestamp of the revision your edit is based on) should
be sufficient. I might be missing something, but I can't think of a
1. Get the ID and timestamp of the last revision.
2. Get the text of that revision.
3. Do long-running computation based on that text.
4. POST an edit (resulting from that computation) with basetimestamp set
to the timestamp obtained in #1.
will cause a race condition.
IIRC there'll still be some race conditions in the sense of programs due to
that smart merge:
1. User A and User B fetch text;
3. User A moves paragraph 1 after paragraph 10 in their copy;
4. User B moves paragraph 1 after paragraph 20 in their copy;
5. User A and User B upload their modified text. The order of uploading
actions is not critical;
6. Result: both edits got accepted; paragraph 1 got duplicated after
paragraph 10 and 20 and removed from its original position.
just like what we do on Web UI. The key is we want to detect any mid-air
edits and abort actions in this case, instead of trying to have my edit
merged to any mid-air revisions.
Wikitech-l mailing list