Ticket #9 (closed defect: worksforme)
Editing "Hatta generate merge conflilcts on its own"
| Reported by: | sheep | Owned by: | sheep |
|---|---|---|---|
| Priority: | High | Milestone: | 1.4.0 |
| Component: | Hatta Wiki | Version: | 1.3.3dev |
| Keywords: | Cc: |
Description
127.0.0.1 - - [25/Nov/2009 20:53:46] "GET / HTTP/1.1" 303 - 127.0.0.1 - - [25/Nov/2009 20:53:46] "GET /+edit/Home HTTP/1.1" 404 - 127.0.0.1 - - [25/Nov/2009 20:54:11] "POST /+edit/Home HTTP/1.1" 303 - 127.0.0.1 - - [25/Nov/2009 20:54:11] "GET / HTTP/1.1" 200 - 127.0.0.1 - - [25/Nov/2009 20:54:19] "GET /+history/Home HTTP/1.1" 200 - 127.0.0.1 - - [25/Nov/2009 20:54:24] "GET /+history HTTP/1.1" 301 - 127.0.0.1 - - [25/Nov/2009 20:54:24] "GET /%2Bhistory/ HTTP/1.1" 200 - 127.0.0.1 - - [25/Nov/2009 20:54:27] "GET /link%3C/a%3E%3Cscript%3EMalware%3C/script%3E HTTP/1.1" 303 - 127.0.0.1 - - [25/Nov/2009 20:54:28] "GET /+edit/link%3C/a%3E%3Cscript%3EMalware%3C/script%3E HTTP/1.1" 404 - merging Home warning: conflicts during merge. merging Home failed! merging Home warning: conflicts during merge. merging Home failed! 127.0.0.1 - - [25/Nov/2009 20:54:47] "POST /+edit/Home HTTP/1.1" 303 - 127.0.0.1 - - [25/Nov/2009 20:54:47] "GET / HTTP/1.1" 200 -
This is a short trace of a normal session being alone editing the wiki
$ ./hg version Mercurial Distributed SCM (version 1.4+19-b22ff29a3fbb) Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $
Change History
Note: See
TracTickets for help on using
tickets.
Can you reproduce that? If so, can you also post the content of the Home page before the conflict and after it? Ideally I'd like to see the whole mercurial repository (so that I can look at its history). Are you sure that nothing edited the 'Home' page outside of the wiki? This is the current development version of Hatta, is it? Thank you a lot for catching and reporting it, I'm still not 100% confident about the merging code. -- Radomir Dopieralski
Hmm... I think I see what is happening here:
You display the edit page for Home, because it didn't exist yet.
You save the page as revision one.
Now, there is no log of visiting /+edit/Home again, so you must have it saved somewhere, with empty page in it.
Then you use that saved edit page to post again:
And as expected, you get an edit conflict: attempting to edit the same revision of the page two times.
This is the expected behavior in this situation, it's the same as if two users edited the same page at the same time.
I don't really get your explanation, as I'm sure I did not played with the mercurial repository or with the Home page in between (At the time it occurred, I only had one tab of Firefox opened to hatta, and really did not did anything else).
Actually, looking at the resulting Mercurial repository, we have two commit for the Home page each one of them with parent revision "-1".
That's one trouble.
The second one (which is highlighted by the first one), is that Mercurial tries to merge twice the content of the file (as seen in hatta log file). Before merging the second time, we should probably cleanup the result of the previous merge.
About the first issue, it seems that visiting /+edit/Home just after visiting /+edit/link%3C... triggered the merge by thinking the base revision of Home is "-1". No idea how did I jumped from one edit page to another though.
That's another illustration of what I think is the same bug (also running with the dev version):
{{conflict-hatta.png}}
-- Ben
It's the POST that triggered the merge -- the log line with POST is written *after* it's all handled, so after the merge, but it's during the POST that it happens.
Both revisions have the same parent revision, because you were editing the same version of the original page (in this case -1, which is non-existing page). My guess is that you came back to the old editor page using your back button, and submitted the form again. That has to generate a conflict, it's the same as two people editing the page at the same time.
The double-merge is a problem, and I need to look into it -- I've tried to track it down but failed so far. You may be right about removing the merge markers first, I will investigate that lead. Thanks for taking your time. -- Radomir Dopieralski
What seems to happen, because I can't remember pressing the back button of my browser is that something is skipping the fact that the page has been updated. As if I were being served a cached version of the /+edit/Home page (containing an outdated parent information) with the current version of the Home page. Could it be possible ?
Actually, I'm also maybe running the dev version of Werkzeug ... could also be the trouble ...
-- Ben
Thinking about it, your description with the "back" button of the browser makes perfect sense, only, I'm sure that I did not pressed that button, I know that pressing back to go to a form page may have strange consequences, but now that I think about it, this simply reminds me to another strange thing I did not filled a bug for as I have no idea when and how it occurs, the less I can say is that for some pages, viewing the history of the page does not show the last edit. As Hatta also uses this information (last revision of the current file) to put in the parent field it might just be that it gets it wrong there also. Leading to a wrong merge situation. And we're done ! We found the cause of the trouble. I guess I know one place where this occurs (history not complete) I can look at it tomorrow ...
-- Ben
I'd like to point out that in the log you posted above the edit page for Home is only retrieved once by the browser. There is not even a "not modified" response -- the browser simply didn't ask for a second edit page. This makes me think it's either a bug in your browser (that it cached a 404 page, which it shouldn't do), or in the configuration of some transparent proxy along the way (for example if you use one to filter out ads). -- Radomir Dopieralski
I cannot deny that you seems to be right ... I reproduced it again multiple times, but unfortunately without easy access to the logs though ...
The case where it seems to occur is when I realize that I made a typo by viewing the rendered page, then quick click Edit and at the next Save, conflict markers wil appear. Time seems to be an important factor there. Any advices further to dig that annoying trouble ?
-- Ben
What browser and version of it are you using? Does that also happen with other browsers? I can try adding an explicit "no-cache" headers to the editor forms, maybe that would help... -- Radomir Dopieralski
I have it on a really annoying frequence with Chrome. Had it only once with Firefox (the one that started this thread).
Follow a new batch of logs That I hope will let you identify the trouble
Sorry for batch posting :-(.
Picture of the repository:
{{hatta-merge.png}}
hg logs:
apache logs:
Hope that helps fixing it ...
-- Ben
PING !!!
-- Ben
I will try that patch tomorrow:
hatta.py
Sincerely hope that will solve it !
--Ben
I'm now convinced that the bug is software. I added the patch above, and ... it's still buggy. then I added the current date of the page inside the page to see if I'm looking at a freshly generated page or at a browser cached page by using the following helper function:
The page is always a fresh and I still have the trouble of the unwanted merge. The only conclusion to that is that the log that initiated this page don't describe the trouble I experience daily.
So, I am now sure that it doen't comes from the cache of my browser. I cannot disclose the repository I'm running hatta on , but I should be able to run some test commands inside it. What it still could be:
So i'm still being hardly bitten by hatta almost each time I am editing a page.
-- Ben
Hatta does no caching on its own -- it relies on the browser and intermediate proxies for that instead. So the only thing left is improper generation of the "parent" input field. This could actually be possible, but I'm wondering why I'm not stumbling upon it, and why it doesn't happen on this wiki and the test one... How are you running your wiki instance? Do you have cherrypy installed? Or maybe you are using mod_wsgi with multiple processes? -- Radomir Dopieralski
I have put the results of some of my experiments on the WikiFeatures:BackButtonFriendliness page. Still no perfect solution. -- Radomir Dopieralski
Are you still having problems with that?
I have to admit that I did not got that trouble for some time. Might be solved ... I'm now sure, it was not the BackButton by the way.
I'm still wondering if it was caused by a wrong calculation of the parent revision. I read lastly that on a merge changeset only the files that are different from both side are listed. I experimented with another way to calculate this revision there if you want to take a look.
As nothing happen (correct me if I am wrong) on this side, I'm wondering if this has really been solved ...
--Ben