On Thu, Jan 23, 2014 at 9:22 AM, Matthew Flaschen <[email protected]>wrote:
> 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 > scenario where: > > 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. -Liangent > > Matthew Flaschen > > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
