[Bug 954556] New: After upgrading from 13.2 to Leap 42.1, Mercurial chokes on files locally deleted and ignored, but changed on the remote
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 Bug ID: 954556 Summary: After upgrading from 13.2 to Leap 42.1, Mercurial chokes on files locally deleted and ignored, but changed on the remote Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 URL: http://users.skynet.be/antoine.mechelynck/vim/vim-tony mec.bundle.bz2 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening@forge.provo.novell.com Reporter: antoine.mechelynck@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I'm not sure if this bug is in the correct Component. It concerns a difference between the Mercurial versions for openSUSE 13.2 and openSUSE Leap 42.1. I'll describe below the problems I had (in a Mercurial repository with local changes) after upgrading to Leap 42.1, and how I solved them (probably not ideally), in the hope that something can be found to make life easier to anyone else running into the same (or a sufficiently similar) problem. FWIW I've uploaded at http://users.skynet.be/antoine.mechelynck/vim/vim-tonymec.bundle.bz2 a full bundle of my local Vim repository, including a clone of the Mercurial mirror at https://bitbucket.org/vim-mirror/vim with local changes. The bundle is 8.8 MiB for a repository occupying about 151 MiB so I didn't attach it to this bug. The tip before I upgraded to Leap 42.1 was the merge commit about 30 changesets from the present tip. The earlier changesets (0 to 7225) are probably not as interesting but I didn't know how else to let you look at it from my point of view. It might be possible to inspect the bundle without unpacking it, by declaring it as a "repository" by means of the -R argument to Mercurial. This past weekend I upgraded to Leap 42.1 and a few hours ago "hg in" displayed 27 new changesets. I tried to "fetch" them but instead of saying "remote changed runtime/doc/tags which local deleted" and asking me if I wanted to download the changes or keep deleted, Mercurial errored out with the new changesets applied, the "old" merge still current, no new merge done, and a message saying that it could not proceed because of a locally ignored file changed on the remote (the deleted file in question). I goofed around some, updated (not easily) to 0 and back to tip, including a couple of manual merges for which Mercurial invoked vimdiff as my preferred merge tool, and finally added one monstrous changeset by hg addremove followed by hg commit. Those "added" files are IIUC files ignored by my locally modified .hgignore on the other unnamed branch. After that I could finally merge my local changes with the monstrous changeset I had just added on top of Bram's official tip. After that I notice that "hg diff" on the locally deleted file does not give the same output as it used to before the upgrade to Leap. Previously it showed a diff between the remote version of the file and /dev/null, which was longish and looked messy, but, well, I used to think that was the way of things, at least with that version of Mercurial. Now it just says: diff --git a/runtime/doc/tags b/runtime/doc/tags deleted file mode 100644 which I find much neater even if it is not visually reversible. I am practically certain that what I did was not the "ideal" thing to do, but it is the best I could find to work around this change of behaviour and still get a working directory tree with which I could compile Bram's version with my local changes (which consist of one feature added and one disabled in src/feature.h, plus .hgignore lines for runtime/doc/tags which is regenerated by "make install" anyway, and for some directories and files not present on the remote, e.g. "shadow" directories allowing me to compile a Huge and a Tiny build in parallel from the same source with different config settings passed as environment variables). I hope Mercurial won't choke again the next time new changesets are added at the remote and I try to apply them. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 Tony Mechelynck <antoine.mechelynck@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Found By|--- |Community User Whiteboard| |[regression Leap 42.1 vs | |openSUSE 13.2] -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c2 --- Comment #2 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- On 13.2 it was the version from openSUSE with all software updates to date if any, but since it's gone I can't specify it with more precision. On Leap, "hg --version" (when run at the top of the problematic repository) answers: Mercurial Distributed SCM (version 3.5.1) (see http://mercurial.selenic.com for more information) Copyright (C) 2005-2015 Matt Mackall 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. Enabled extensions: churn color fetch graphlog strip mq pager progress Yes this is out of the box from openSUSE. I wonder where "strip" comes from (or is it from mq?) Running "hg --pager=yes showconfig" in the same directory shows *no* "extensions.strip" line. Otherwise all extensions.* lines have nothing after the equal sign. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 Tony Mechelynck <antoine.mechelynck@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(antoine.mechelync | |k@gmail.com) | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c3 --- Comment #3 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- Had it again, but my workflow is improving a little: 1) "hg fetch --switch-parent" still does a pull but aborts the merge: $ hg fetch --switch-parent || echo 'exit status' $? ; date pulling from https://bitbucket.org/vim-mirror/vim searching for changes sampling from both directions adding changesets adding manifests adding file changes added 13 changesets with 34 changes to 23 files (+1 heads) resolving manifests 0 files updated, 0 files merged, 0 files removed, 0 files unresolved merging with 7275:8896150aba23 resolving manifests runtime/doc/tags: untracked file differs abort: untracked files in working directory differ from files in requested revision exit status 255 Thu 19 Nov 22:32:03 CET 2015 2) then after updating to the latest common ancestor and back to the newest pulled changeset: $ hg merge -r 7262 resolving manifests local changed runtime/doc/tags which remote deleted use (c)hanged version or (d)elete? d removing runtime/doc/tags [...] 103 files updated, 0 files merged, 1 files removed, 0 files unresolved (branch merge, don't forget to commit) $ hg commit -m 'merge local with https://bitbucket.org/vim-mirror/vim' committing files: [...] committing manifest committing changelog committed changeset 7276:01ce4237faad N.B. - revision 7262 (decimal) was the tip before the fetch - Under 13.2 the fetch succeeded, telling me "remote changed runtime/doc/tags which local deleted" instead (since we were on the other branch) - I'd prefer to see fewer files "updated" by the merge step, as it used to be under 13.2. I think it makes a difference to the following "make" (does it react the same way to a file left in place and to a file removed then added back?). - Strangely enough, the "hg log" entry for the merge commit mentions only one file (the one I removed by answering d at the prompt), not 103. - By doing "hg diff" between the new tip (the merge commit) and one of its parents, I notice that some files listed in .hgignore (linkable objects from a previous "make", apparently) have been "added". Is this normal? (The .hgignore uses glob syntax, its first line is "syntax: glob", and no other line starts with "syntax".) It seems the merge succeeds in one direction and fails in the other one, while obtaining (AFAICT) the same result in the working directory. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c4 --- Comment #4 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- When there is no remote change to the locally deleted-ignored file, fetch (pull + merge) works OK. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c5 Tony Mechelynck <antoine.mechelynck@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|[regression Leap 42.1 vs |[regression Leap 42.1 vs |openSUSE 13.2] |openSUSE 13.2] [CLOSEME | |2015-12-27 WFM] --- Comment #5 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- Somehow it went back to normal today: Mercurial (still hg 3.5.1) asked remote changed runtime/doc/tags which local deleted use (c)hanged version or leave (d)eleted? and did the merge after I answered d. Let's declare this WORKSFORME if it doesn't reappear within a month. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c6 Tony Mechelynck <antoine.mechelynck@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|[regression Leap 42.1 vs |[regression Leap 42.1 vs |openSUSE 13.2] [CLOSEME |openSUSE 13.2] |2015-12-27 WFM] | --- Comment #6 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- # hg fetch --switch-parent || echo 'exit status' $? ; date pulling from https://bitbucket.org/vim-mirror/vim searching for changes sampling from both directions adding changesets adding manifests adding file changes added 5 changesets with 17 changes to 15 files (+1 heads) resolving manifests 0 files updated, 0 files merged, 0 files removed, 0 files unresolved merging with 7362:444efa5f5015 resolving manifests runtime/doc/tags: untracked file differs abort: untracked files in working directory differ from files in requested revision exit status 255 Sun 6 Dec 07:00:18 CET 2015 Inspection showed that "hg fetch" had pulled the new changesets but not merged the new tip with the current revision or changed which revision was current (an automated merge from a previous fetch which hadn't changed the untracked file). Updating to the new tip or to its common ancestor with the current revision was not possible except after manually deleting the untracked file. After manually deleting the untracked file (and nothing else, in particular no commit yet), Mercurial accepted to update to the new tip and back, and then: # hg merge -r tip resolving manifests remote changed runtime/doc/tags which local deleted use (c)hanged version or leave (d)eleted? d getting .hgtags getting runtime/doc/eval.txt getting runtime/doc/filetype.txt getting runtime/doc/if_ruby.txt getting runtime/doc/todo.txt getting runtime/syntax/r.vim getting runtime/syntax/vhdl.vim getting runtime/syntax/vim.vim getting src/normal.c getting src/proto/window.pro getting src/testdir/Makefile getting src/version.c getting src/window.c merging src/Makefile 13 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) # hg commit -m 'manual merge' committing files: .hgtags runtime/doc/eval.txt runtime/doc/filetype.txt runtime/doc/if_ruby.txt runtime/doc/todo.txt runtime/syntax/r.vim runtime/syntax/vhdl.vim runtime/syntax/vim.vim src/Makefile src/normal.c src/proto/window.pro src/testdir/Makefile src/version.c src/window.c committing manifest committing changelog committed changeset 7363:439f55eac0c0 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c7 --- Comment #7 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- Running "hg diff" between the tip of the latest merge and its remote parent (hg --pager=yes diff -r 7381 -r tip) shows a lot of "new" files which are, however, mentioned in .hgignore. These files are a few symlinked directories with a strange line "\ No newline at end of file" at the end, objects (*.o), executables (no extension on Linux, but mode +x, and known names), "compiled" dictionaries (*.mo), and a few sources in src/auto/ (auto/*.h), all of which are regenerated by make whenever they are seen to be out-of-date with the corresponding sources or with whatever the makefile makes them depend on. IMHO anything mentioned in .hgignore should be missing from the Mercurial records and in particular from the diff I ran. I wonder what went wrong where but as long as compilation works (and gives me the expected executable) I'm going to regard it as a strange quirk rather than as a bug. The only reason I'm mentioning it at all is that it might be a symptom of something I'm not aware of. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c9 Tony Mechelynck <antoine.mechelynck@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Version|Leap 42.1 |Leap 42.3 Resolution|WONTFIX |--- Whiteboard|[regression Leap 42.1 vs |[regression Leap 42.1 vs |openSUSE 13.2] |openSUSE 13.2] [workaround | |see comment #9] OS|openSUSE 42.1 |openSUSE 42.3 --- Comment #9 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- AFAIK the bug is still there but I found a workaround, which I forgot to report in this bug: • Always run "hg in" before actually pulling • If there is a change to the problematic file (ignored on local but not on remote), delete it explicitly on the local clone (in the case of ./runtime/doc/tags for a Vim clone, "make install" will rebuild it anyway) • Now "hg fetch" will again give the prompt it used to do on openSUSE 13.2 and before (slightly changed from the one in comment #6 above, and with more options). The answer is "d" (leave Deleted) which won't pull the file from the remote. My current version of Mercurial is 4.2.3-12.1, installed April 4 from the openSUSE 42.3 Update-Test repo. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c11 Tony Mechelynck <antoine.mechelynck@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Leap 42.3 |Leap 15.1 --- Comment #11 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- In reply to comment #9: I haven't tried to intentionally reproduce the bug. The workaround mentioned in comment #9 works, but if I forget to delete the problematic file, and there are upstream changes to it, "hg fetch" will pull the changes but not merge them and I have to delete the file manually ("make" will recreate it the next time I build) and then "update" my clone to the appropriate changeset to "merge" the changes manually. I suppose (and regret) that this bug will remain WONTFIX. Anyone willing and able to solve it, feel free to REOPEN it and ASSIGN it to yourself. Or report it to Mercurial if that's where it should be solved; but the Mercurial guys will propably answer: "You're using an old version of Mercurial; upgrade to the latest version first, and then we can talk business." -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954556 http://bugzilla.opensuse.org/show_bug.cgi?id=954556#c12 --- Comment #12 from Tony Mechelynck <antoine.mechelynck@gmail.com> --- oops: comment #11 was in reply to comment #10. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com