Re: [Winmerge-development] Compare lib and new diffutils version

[Gal H. <gal...@gm...>]

On 10/23/06, Kimmo Varis <ki...@wi...> 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.
>

Agreed.

    Gal.