On or about 2009 Jan 4, at 4:59 PM, Steve Borho indited:
> 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 find it humorous to consider Python and GTK as "native" on Windows...
But that aside, it seems to me to be improper software construction
technique to break down the encapsulation barriers of these tools.
Specifically, TortoiseHG uses Mercurial, Mercurial uses "a diff/merge
tool"... If TortoiseHG starts to favor and then become intertwined
with the code from a "favored" diff/merge tool, how will that impact
TortoiseHG's testing and reliability? (commit tools sit on top of
Mercurial and are a reasonable UI wrapping)...
I agree that in the Mercurial world, there are too many "patch
analyzing" parts (shelve, record, Qct's version of record, etc.). I
don't think intermingling TortoiseHG with a favored tool makes that
any better.
(Just my $0.02, as I have been dealing with family medical issues for
the past 9 months and unable to put any nose to the grind stone (no
skin in the game) as to making changes, etc.)
Fortunately, by the time any of these tools mature, we'll have gotten
facile with kdiff3 and probably moved to a path where we'll be
comfortable supporting that if the TortoiseHG installer moves in other
directions and the native tools don't meet our kdiff3-primed needs. I
understand all too well the tensions of modularity vs. all-in-one-
control-everything (I use a Mac after all, when I have a choice in
what I use). :)
Thanks for listening,
--Doug
------------------------------------------------------------------------------
_______________________________________________
Tortoisehg-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
