--- Rowan Collins <rowan.collins(a)gmail.com> wrote:
Second, how come I see no attachment: is it my
fault, yours, or the
mailing list software's?
Third, are you going to copy this to the said
bugzilla report,
attachment and all? Apologies if you're on your way
there now, but
there's little point in a dedicated bug database if
we just go and
discuss the bugs somewhere else...
Sorry, I didn't realize that the list had a problem
with attachments. I have uploaded the patch at
http://bugzilla.wikipedia.org/show_bug.cgi?id=56 .
Discussing the patch there is fine with me if that is
more appropriate.
So hang on, I'm not quite clear on this: what
happens to the edits
since 'the time editing began'? Or am I completely
miunderstanding? Or
Say that user A and user B both load the edit page at
the same time, and user B is editing a section (it's
not important whether A is doing a section or regular
edit). User A submits a change that inserts (or
removes) a section above user B's section.
This changes the section index of user B's section, so
when he or she submits, the wrong section gets
replaced. The edit conflict merging code can't detect
this case.
My fix is for user B's submission to use the revision
at the time that user B loaded the edit form, rather
than the current revision (which user A has modified).
is this just a proof-of-analysis type patch, not an
actual
ready-for-inclusion fix?
This patch should be ready for inclusion unless
someone sees a problem with it. In the long run it
might not be the most efficient way of doing things.
With my patch, in the case of an section edit conflict
the database is queried for the old text twice: in
EditPage::mergeChangesInto() and
Article::getTextOfLastEditWithSectionReplacedOrAdded().
But I think my patch is the most straightforward
solution for now.
-- Wil
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com