On Mon, Jan 5, 2009 at 6:47 AM, Peter Arrenbrecht <[email protected]> wrote: > 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
Looks like it's won't run on Windows yet. ------------------------------------------------------------------------------ _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
