On 17/07/12 01:49, Adam Wight wrote: >> Actually, the revision table allows for non-linear development (it >> stores from which version you edited the article). You could even make >> to "win" a version different than the one with the latest timestamp (by >> changing page_rev) one. >> You will need to change the way of viewing history, however, and add a >> system to keep track of "heads" and "merges". >> There may be some assumtions accross the codebase about the latest >> revision being the active one, too. >> > 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. > -adam
Not really. The would be lost in favour of the target ones. You keep a list of rev_ids in the source wiki and the ones it gets in the target wiki, adjunting following rev_parent_id to the target wiki numbers. It could be a problem for merges after the first one, but it's good enough for the first version. The nasty problem I see is how to determine the winner in a version conflict: B / A \ C B and C both are revisions with common parent A. How do you handle the merge? What revision should be shown in the title? _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
