On Mon, Jan 5, 2009 at 1:52 AM, TK Soh <[email protected]> wrote: > On Sun, Jan 4, 2009 at 9:59 PM, Steve Borho <[email protected]> wrote: >> On Sun, Jan 4, 2009 at 2:46 PM, Douglas Philips <[email protected]> wrote: >>> >>> On or about 2009 Jan 4, at 3:29 PM, Steve Borho wrote: >>> > The thgconfig dialog already has most of these smarts in it. The >>> > drop-down box for ui.merge is seeded with the merge tools defined in >>> > your Mercurial.ini file(s) that pass the hg built-in detection >>> > tests. So long as we include configuration for all those tools in >>> > the base installer, your favorite diff tool will show up in that >>> > drop-down list if it is installed. >>> > >>> > I want to repeat my initial sentiment, though. I don't know that >>> > diffuse is sufficiently stable/complete to be able to function in >>> > this role, but I think it should be a long-term goal of TortoiseHG >>> > to find such a native tool. >>> >>> So you think that TortoiseHG should *ship with* its own "preferred >>> merge tool"? >>> >>> If so, is the problem with kdiff3 just one of packaging, or of it >>> being too unixy regardless of packaging? >> >> If kdiff3 were a python and GTK app, I think we would gladly use it as our >> built-in diff/merge tool. Having a native tool is just more efficient, both >> at >> runtime and in the THG installer. A native tool's code could be reused by >> THG to make new dialogs (perhaps for the record extension). > > I agree with Steve on this.
Meld comes to mind. Though: http://www.mail-archive.com/[email protected]/msg00395.html -parren ------------------------------------------------------------------------------ _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
