Wednesday, September 26, 2007

Fixing the Patcher (part 1)

This week I've started to work on bug 199846. Frankly speaking, I was shocked after I'd discovered that the mysterious fuzz factor is not what it should be. Probably I wasn't the first guy who did it, but first who dare to log in on Bugzilla.

First, I read what Eclipse Help says about the fuzz factor. You can find the information here (paragraph "Options for applying a patch", point 4). Now you know why I'm calling it mysterious. I knew that I will need more details on that topic to start fixing the bug. After googling around I came across these two pages:
They both gave me a fair background of the fuzz factor so I could to start working on it. Next step was to get familiar with classes involved in the patching mechanism. The story should start with Patcher and WorkspacePatcher classes. This is where a patch is loaded, parsed, applied and so on. Let's take a closer look at classes which represent structure and content of a patch. Here a sample patch file:





DiffProject - "A diff project represents a project that was read from a workspace patch. It contains the set of file diffs that were associated with the project in the patch file."

FileDiff - "A file diff represents a set of hunks that were associated with the same path in a patch file."

Hunk - "A Hunk describes a range of changed lines and some context lines."
All above classes are located in org.eclipse.compare.internal.patch package of the Compare project so they are internal and there is no javadoc generated for them.

Classes that hold result of the patching process are: FileDiffResult and HunkResult.

To be continued...