I have a need to modify large #'s of files.
I was thinking of how merging multiple files together (say from 3 different sources of the same file into a new 4th file) is a tedious task. I would have to inject one file, then inject another file on top of the 1st one.
Issue would become more profound if 2 files modified the same area. Patch files would break and kick out rejects.
The entire time I was thinking, how annoying... I can't use a patch file in a contextual manner. So I googled, and I found.
with a built in gui front-end providing examples of it's use provided here.
Capabilities to match based on fuzzy logic, the ability to derive a patch file from two side by side windows, and the ability to apply a fuzzy logic patch.
I was thinking, that's exactly what patch files need, a gui front end. If the match % is too low, we can go to the area in the file, and display the match(es).
In fact, a file could be loaded in the left window, and a dry-run output could be applied to the right window. Something diff needs really bad. area's that couldn't be matched properly could be left blank, and outputted to a window displaying what blocks of diff's could not be found/applied, match's could be highlighted in the window's kind of like kdiff3 does, using colors. Winmerge could use it's default yellow for matches in a "match-only mod".
I have some programming experience. I've never built an application from the ground up, but I have contributed to Dwarf Therapist, an opensource QT project; although my actual hands on programming is generally specific to an individual task. I think I might be able to do something with this and would like to source a copy of the code on my github and see what I/we can do with it.
Oh yeah. I think applying patches in reverse (as in starting @ EOF and working your way up) is a way better way to apply a patch file. Generally contextual doesn't care about line #'s. But... if the file is largely unchanged. The line #'s would match up vs injecting/deleting code to prior points and having to keep track of all that.
I know winmerge already has the capability to derive a patch file, but I think in this case, if a patch file could be derived between two files, and apply that patch to a 3rd file by opening it in the left pane, and clicking some sort of "compute patch" that asks for a previous derived patch file and applies it to the right pane would be a great feature of winmerge.
Ironically I'm more familiar with QT than the other IDE that I'm not even aware of, so I might be basing this on v3.
I'll post a github link once I get everything up and running.
So far [the source supplied for] winmerge v3 (QT) is just a skeleton ATM [so I switched to v2_14].
So I did host winmerge 2-14 on github and I was able to build it, but I ultimately decided to try a "concept" mockup in QT first.
https://github.com/thistleknot/winmerge ... its/master
I have another repository I'm "rebuilding" that for some reason I wasn't able to rebuild a working executable that has the google-diff-match-patch source files built in. I will put link up later. Having some minor issues with 4.8 to 5.3 ATM.
Bye the way. Google-diff-match-patch is based on QT 4.8. I do not know how big of an issue that is to port to VS 2008 and may be outside of my area of expertise (but... there are other versions of the code, google does a good job of porting their apps to a plethora of environments). If it comes to that point where I'm stuck, I'll reach out for help.