I have a TeX project managed with Mercurial, I am using mq. I have a patch here that I regularly pop and push as needed. Today I updated my hg to 4.6rc0 and after that when the patch was popped and a bit later pushed again, push ended with several warnings “Hunk succeeded with fuzz…” and even some errors “Hunk FAILED…”. When I downgraded hg back to 4.5.3, the patch worked all right again. I cannot attach the patch itself as it contains bulks of copyrighted text but since it is TeX it also contains some TeX markup, i.e. a lot of backslashes, tilda-chars for hard spaces and such. Hope this helps.
We also have some issues applying patches since 4.6rc0
Boris, can you attach the patch that reproduces the issue? If you didn't run "make clean local" after updating to 4.6rc0, please do. Anton says something broken on in-place upgrade without rebuilding, in Bug 5845.
(In reply to Yuya Nishihara from comment #2) Hi, I for one always do clean hg build, as I do each of my builds on fresh clone of my local hg-sources repo.
Can you test if qpush worked/works with the pure Python implementation? $ HGMODULEPOLICY=py hg-4.5.3/hg qpush $ HGMODULEPOLICY=py hg-4.6rc0/hg qpush
(In reply to Yuya Nishihara from comment #4) With HGMODULEPOLICY=py the result was the same, however when I tried `make local` 4.6rc0 worked from its local directory just fine: qpush succeeded with no problems. So it would seem there is something in the installation directory (or directories: I do not use prefix so it goes into /usr/local subdirectories, mostly lib/ of course) from previous versions that makes trouble.
I observed this once with `hg record`, but was in the throes of something urgent and so didn't have time to investigate. Marking confirmed since we've got so many reports, and it's a release blocker. Folks, we desperately need an example diff so we can ship 4.6 in a few days.
Oh, I missed that this seems to be related to stale .py/pyc files in the target install directory. Hmm. We should figure out what the cause is, and see if we can prevent it?
The content of the patch doesn't seem relevant, we don't have the problem anymore locally, will try to reproduce somewhere else.
It seems that every that the first hunk for every file fails to apply. We had the problem even after running `make clean build` and even `hg purge --all`.
Perhaps diffhelpers.py would be shadowed by diffhelpers.so of Mercurial <= 4.2.3. I'll rename the module.
(In reply to Yuya Nishihara from comment #10) That seems to be the case: I've just sort of bisected the problem, i.e. made several builds for older versions and then put 4.6rc0 build over it, when I found one that made trouble and one that didn't I did diff on their respective file lists and then tried to remove, one by one, those files that wrong version had extra. After removing lib/python2.7/site-packages/mercurial/diffhelpers.so the wrong version started to work correctly. So then I did the same again, but instead of removing extra files one by one I only removed that diffhelpers.so and it still worked all right.
Fixed by https://mercurial-scm.org/repo/hg/rev/72f6498c040b Yuya Nishihara <yuya@tcha.org> diffhelper: rename module to avoid conflicts with ancient C module (issue5846) Historically we had had C extensions in mercurial/, which shadows the pure Python modules of the same name forever unless we do clean build/install. I'm sloppy to think about new name, so just dropped the "s". (please test the fix)
(In reply to HG Bot from comment #12) This fix works for me. Thanks for your work. (I do not know the workflow here: should I, as a reporter, close the bug or should I leave to product owner/developer/you name it? Thx)
Typically we let our bot mark things as fixed after a week, but in this case I'm confident enough that 4.6rc1 fixes this I'll close the bug. :)