Bug 131574 - [Patch] Apply workspace patch guesses bad fuzz factor
Summary: [Patch] Apply workspace patch guesses bad fuzz factor
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M4   Edit
Assignee: Tomasz Zarna CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 137222 206790 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-03-13 13:46 EST by Markus Keller CLA
Modified: 2007-12-11 11:31 EST (History)
3 users (show)

See Also:


Attachments
Fuzz factor set to 0 by default (3.76 KB, patch)
2007-10-20 08:47 EDT, Tomasz Zarna CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2006-03-13 13:46:59 EST
I20060309-1000

- have org.eclipse.pde.ui v20060307 and another project from CVS
- select the other project and choose context menu > Team > Apply Patch
- apply patch from attachment 34143 [details] (bug 45408)
- on the Verify Patch wizard page, press the Guess button
-> Maximum fuzz factor is set from 2 (default) to 0. This makes the last change not match any more, although is was fine with fuzz factor 2.

Note: fuzz guessing works fine for the project that was the target of the Apply Patch action.
Comment 1 Michael Valenta CLA 2006-07-10 13:05:52 EDT
*** Bug 137222 has been marked as a duplicate of this bug. ***
Comment 2 Tomasz Zarna CLA 2007-10-18 12:20:37 EDT
Markus, I would like to check whether this bug is still valid (especially after fixing bug 199846). Could you explain to me what did you mean by "another project from CVS"? Should I check out also org.eclipse.jdt.unit and org.eclipse.jdt.ui.tests projects (they are both mentioned in the patch)?

At the same time I'm aware that this bug more then a year old, so I could mark it as RESOLVED and if you still encounter any problems with the fuzz factor we could log a new bug for it.
Comment 3 Markus Keller CLA 2007-10-19 08:48:23 EDT
(In reply to comment #2)
> Markus, I would like to check whether this bug is still valid (especially after
> fixing bug 199846). Could you explain to me what did you mean by "another
> project from CVS"?

"another project" was just any other project, e.g. "org.eclipse.core.expressions".
The diffs in the jdt projects do not matter for this bug and can be disregarded.

When I execute the steps from comment 0 in I20071017-1638 (it doesn't even matter any more on which project I call Apply Patch), the wizard first opens with
"Maximum fuzz factor: 2", and the JUnitWorkbenchShortcut.java contains a diff with a red exclamation mark icon.

=> Expected: diff should be OK with initial fuzz factor 2.

When I press "Guess", the exclamation mark disappears and the "Maximum fuzz factor" stays at 2. From then on, everything is OK.

It looks like the only thing left to do is to really apply the max fuzz factor 2 initially, not only after "Guess" has been clicked.
Comment 4 Tomasz Zarna CLA 2007-10-19 09:35:17 EDT
I do agree that the "Guess" button is somehow arguable[1], but I think that we shouldn't use the fuzz factor initially (i.e. shifting should be done automatically whereas the fuzz factor should be applied/guessed only when requested[2]).

[1] bug 29793, comment 3
[2] bug 196847, comment 6

Comment 5 Michael Valenta CLA 2007-10-19 09:45:00 EDT
When I apply a patch and initially see that there are some hunks that don't mathc, I always just click the guess button. For me, I would like to be able to set a preference that will always guess the fuzz factor and I would like the UI to show me what fuzz factor was used and how many hunks wouldn't have matched if the fuzz factor wasn't used.
Comment 6 Markus Keller CLA 2007-10-19 10:24:00 EDT
(In reply to comment #5)
Sounds good.

Is the guessing of the fuzz factor really that expensive? If I see that right, the patch is currently checked with the new factor as soon as I change the integer in the fuzz factor field (on keystroke). If it's fast enough, I'd not introduce a preference at all and execute the guess action automatically if there was an unmatched hunk.

Maybe you could also execute it automatically but allow the user to cancel if it takes too long.

If you cannot guess automatically, you should at least set the field to 0 by default to show that no fuzz was used initially (whatever a "fuzz" is;-).
Comment 7 Tomasz Zarna CLA 2007-10-20 08:47:52 EDT
Created attachment 80820 [details]
Fuzz factor set to 0 by default

I must admit that I'm not convinced that we should automatically adjust the fuzz factor. I'd rather we kept things as they are now (see comment 4), so the patch simply sets the fuzz factor to 0 by default. At the same time I changed the label  for the fuzz factor as it's no longer the "maximum fuzz factor" but the "actual, used fuzz factor". The maximum fuzz factor is a hard-coded constant in HunkResult class. Also, I added some underscore shortcuts to the Apply Patch wizard.
Comment 8 Tomasz Zarna CLA 2007-10-20 08:50:39 EDT
(In reply to comment #5)
> [...] and I would like the UI
> to show me what fuzz factor was used and how many hunks wouldn't have matched
> if the fuzz factor wasn't used.

This request is addressed by bug 205761.

Comment 9 Tomasz Zarna CLA 2007-11-12 06:15:57 EST
Michael, I've released the patch to HEAD and logged bug 209471 to address your request for the "always-guess-the-fuzz" preference.
Comment 10 Tomasz Zarna CLA 2007-11-12 06:26:39 EST
*** Bug 206790 has been marked as a duplicate of this bug. ***
Comment 11 Tomasz Zarna CLA 2007-12-11 11:31:57 EST
Verified in I20071210-0930.