filemerge regression in 1.9

Matt Mackall mpm at selenic.com
Wed Jul 6 09:20:38 CDT 2011


On Tue, 2011-07-05 at 23:12 -0500, Steve Borho wrote:
> On Tue, Jul 5, 2011 at 10:43 PM, Steve Borho <steve at borho.org> wrote:
> > Since Mercurial 1.9, TortoiseHg is no longer able launch external
> > merge tools from the resolve tool when our app is launched from the
> > shell extension.  All we get is a meaningless error:
> >
> > % hg resolve --traceback -a
> > merging foo.c
> > abort: The handle is invalid
> >
> > Looking at the diffs, I'm fairly certain this was caused by
> > e3be7dc9a5e1, which passes sys.stdout to util.system as an output file
> > handle.  When TortoiseHg is not launched from a command shell,
> > sys.stdout and sys.stderr are *not* valid file handles.
> >
> > I think to resolve this cleanly, ui.fout needs to be a
> > cStringIO.StringIO() or something similar when sys.stdout is not a
> > valid handle (ditto for sys.stderr).  I'm curious how others feel
> > about this.
> 
> I've validated that setting sys.stdout and sys.__stdout__ to point to
> a StringIO instance does make filemerge work again, but this doesn't
> seem like something TortoiseHg should need to do.  We always give
> Mercurial a properly subclassed ui() instance that doesn't use stdout
> or stderr.

That's never been entirely sufficient as there have always been paths
like this one that presume the standard descriptors exist and bypass
ui.write. All that's been done here is that the descriptors are now
managed by the ui object so that they can be properly controlled.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list