Submitter | timeless |
---|---|
Date | Feb. 14, 2017, 4:10 p.m. |
Message ID | <CAAKMeYj84R1BFUXySBb6nEei=4fOrNwgzEwtpJT7GUDSOn+r1g@mail.gmail.com> |
Download | mbox | patch |
Permalink | /patch/18478/ |
State | Not Applicable |
Headers | show |
Comments
On Tue, Feb 14, 2017 at 8:10 AM, timeless <timeless@gmail.com> wrote: > Two points: > 1. The tests afaik are supposed to be self-contained. > 2. The error reporting here was incredibly unhelpful. I shouldn't have > to insert dozens of debug statements to find out that `hg merge` > called an `hgmerge` script and that the script failed. hg should tell > me that it called `hgmerge` and that it failed. > A long time ago, the default external merge program that we looked for was called hgmerge, and there's still backwards compatibility code in filemerge.py to support it. The tests are as self-contained as they can reasonably be, but the only viable way to achieve this is to put a special bindir at the front of PATH. That bindir is prepopulated with special versions of important commands, but hgmerge isn't in that set. The obviously easiest thing to do is delete your local hgmerge script and move on, unless you want to insert a hgmerge command into the special bindir – but I can almost guarantee that doing so will break other tests. Any "more general" attempt at a fix probably won't actually help anyone except you.
Bryan O'Sullivan wrote: > A long time ago, the default external merge program that we looked for was > called hgmerge, and there's still backwards compatibility code in > filemerge.py to support it. Yeah, I have some vague recollection of this. What's odd is that I'm pretty sure my hgmerge script has been on gcc112 for a while w/o breaking anything... > The tests are as self-contained as they can reasonably be, but the only > viable way to achieve this is to put a special bindir at the front of PATH. > That bindir is prepopulated with special versions of important commands, but > hgmerge isn't in that set. I'm half leaning towards this. Specifically trying to do so in a way where we remove the rest of PATH. > The obviously easiest thing to do is delete your local hgmerge script and > move on, This is what I've done so far. > unless you want to insert a hgmerge command into the special bindir > – but I can almost guarantee that doing so will break other tests. > Any "more general" attempt at a fix probably won't actually help anyone except you. Probably, although, most likely it'll help me differently on various different computers :-)
Patch
--- /home/timeless/hg/crewplan/tests/test-merge-changedelete.t +++ /home/timeless/hg/crewplan/tests/test-merge-changedelete.t.err @@ -59,7 +59,8 @@ other [merge rev] changed file2 which local [working copy] deleted use (c)hanged version, leave (d)eleted, or leave (u)nresolved? u merging file3 - warning: conflicts while merging file3! (edit, then use 'hg resolve --mark') + hg: parse error at 0: syntax error in revset '$TESTTMP/repo/file3' + merging file3 failed! 0 files updated, 0 files merged, 0 files removed, 3 files unresolved use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to aband on