Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369744

Summary:

[Search]Compare view diff annotation is one line off on some rare files.

Product:

[ECD] Orion

Reporter:

libing wang <libingw>

Component:

Client

Assignee:

libing wang <libingw>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

Version:

0.4

Target Milestone:

0.4 RC1

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
Screen shot	none

Description libing wang

2012-01-25 16:18:39 EST

I happened to find this rare case while testing today.

1.Search on key word "new". 
2.In the result page, go to ptions->"sort by name" then click on replace and enter "becomeOld".
3.In the preview page, click on annotations.js and expand it.
4.Click on the second match.

In the compare view you will see the changed match is properly highlighted as a pair but the diff block is annotated one line below that.

Not sure if jsDiff is wrong or I am wrong but need investigation for M2.

Comment 1 libing wang

2012-01-25 16:22:25 EST

Created attachment 210084 [details]
Screen shot

Comment 2 libing wang

2012-02-09 18:37:20 EST

fixed with 
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=8ea6c50c1ab37d056be007e4c356417938ee2e84.

Basically the jsDiffAdapter.js assumed that all diff blocks returned by jsdiff.diffLines are the following pattern:

unchanged block (foo\n)
added block or nothing(bar\n)
removed block or nothing(coo\n)
unchanged block (fooo\n)
added block or nothing(baar\n)
removed block or nothing(cooo\n)

But sometimes it returns something like this

unchanged block (foo\n)
added block or nothing(bar)
removed block or nothing(coo)
unchanged block (\nfooo\n)
added block or nothing(baar)
removed block or nothing(cooo)

We should be careful on counting the unchanged block length because at very beginning it may contain a line delimeter that is supposed to be contained in the previous  added/removed block.