On 10/23/06, Kimmo Varis <firstname.lastname@example.org> wrote:
I've thought about our situation with diffutils. We have a old version of diffutils now integrated. And new versions of diffutils have changed *a lot*. Making pure merge very hard and time-consuming task.
You don't need to tell me about it :-(. I had two failed attempts trying to do the update.
However, the fact is that diffutils integration itself isn't very complex thing. Mainly it is:
1) getting it to compile with MSVC
2) exporting couple of functions we need to use (we don't use it through commandline)
Why don't we use it through command line execution? AFAIK, most of the graphical wrapper around console based tool work this way (GNU/Linux systems, for example).
3) creating mapping of diffutils internal structs and structs we use in WinMerge. Currently done in DiffWrapper functions.
So it wouldn't take a long time to get new version integrated.
I wasted some time on it. However, you are probably more familiar with code than I am.
Next question is what to do with our other modifications, EOL handling etc?
I'd say we might be able to just drop lots of those. We made that EOL work with assumption we give unmodified files to diffutils. What if we instead unify EOL bytes before we give files to diffutils. We avoid adding lots of non-trivial and hard to maintain code to diffutils. Are there drawbacks I don't see?
No drawbacks pops up right now.
Moved block code is another thing. But we may end up redoing it also, for library approach.
One big advantage in doing this from fresh start would be we can drop lots of hard to maintain and understand hacks to diffutils.