Bug 60383 - Copy All non-conflicting changes from right-to-left erase left-to-right changes!!!
Summary: Copy All non-conflicting changes from right-to-left erase left-to-right chang...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P2 major (vote)
Target Milestone: 3.0 M9   Edit
Assignee: Andre Weinand CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-29 04:57 EDT by Frederic Fusier CLA
Modified: 2017-07-07 08:24 EDT (History)
3 users (show)

See Also:


Attachments
Snapshot of synchronize view before to push on "Copy All..." button (216.79 KB, image/jpeg)
2004-04-30 06:34 EDT, Frederic Fusier CLA
no flags Details
Snapshot of synchronize view AFTER having pushed on "Copy All..." button (205.14 KB, image/jpeg)
2004-04-30 06:35 EDT, Frederic Fusier CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Fusier CLA 2004-04-29 04:57:13 EDT
Using last integration build I200404281424.

Scenario is still the same than bug 55207, 55289: merge JDK_1_5 branch with 
HEAD.

I now use "Copy All non-conflicting changes from right to left" for all files 
which are in conflict. When there's no line of code in conflict (the light is 
blue on left upper corner...), it's the faster way I found to update changes.

Everything was fine until this last integration build. Unfortunately, this 
button is no longer working as when I push on it, all output changes are 
destroyed and replaced by HEAD contents!

You have to know that I make this merge every 2 days and the average of 
conflicting changes is around 100 files. Sometimes (quite often), some of this 
conflict may have more than hundred changes to get from HEAD to 1_5 stream. I 
cannot imagine getting them one by one...

If it would possible to have a patch asap it would be really helpful thanks
Comment 1 Michael Valenta CLA 2004-04-29 07:06:27 EDT
This button in provided by the Compare component.
Comment 2 Jean-Michel Lemieux CLA 2004-04-29 08:41:35 EDT
I can't duplicate. I've setup for that I have a branch and HEAD, the file in
HEAD has non-conflicting changes compared to the file in the branch. When the
merge completes the file shows as conflicting. When I open the file in the
compare editor I can see both an outgoing (from branch) and incoming (from HEAD)
change. Clicking on the "copy all non-conflicting..." button brings the change
from HEAD into the file and leaves the outgoing change intact.

Andre, also I've looked at TextMergeViewer and don't see any changes related to
this functionality being made in a long while. Frederic, could you please
provide more detailed steps to reproduce? Thanks.
Comment 3 Frederic Fusier CLA 2004-04-29 09:29:20 EDT
Unfortunately, I have no other information to provide... It's exactly the same 
scenario you described.

One precision perhaps: it is the CompilationUnit unit which was selected when 
this problem occured. It works if you only select a modified method which only 
has incoming changes (ie. it does not reset other changes -neither outgoing nor 
incomming- which are outside the selected method). However, I get again the 
problem if the selected method has outgoing changes (conflicting or not...).

I've tried on many different conflicting files, so it seems that history files 
does not matter...

Perhaps it's because I'm using it's an old workspace? Have you tried on a new 
one or an already existing one?
Comment 4 Jean-Michel Lemieux CLA 2004-04-29 09:40:01 EDT
I tested using the latest compare/team/cvs from HEAD.
Comment 5 Michael Valenta CLA 2004-04-29 09:53:51 EDT
I have been able to reproduce this and in fact this is what probably happened 
yesterday when I merged some changes from HEAD into a branch. Outgoing changes 
on the branch were lost. Here's what I did to reproduce this (on Linux-GTK).

1) Checked out org.eclipse.team.core at April 28, 2004 11a.m. Ottawa time 
(using a date tag)

2) Merged the branch branch_20040402_layouOptionsInSynchronizeAdvisor

3) Picked a file with incoming changes (ISynchronizeParticipant)

4) Modified the file locally in a non-conflicting fashion (I changed the 
class' javadoc) and saved

5) Opened the compare editor and clicked the Copy Non-conflicting button

6) The loclal file contents were made equal to the remote and the outgoing 
change was lost
Comment 6 Andre Weinand CLA 2004-04-29 17:42:54 EDT
Frederic, are you saying that in recent builds the "Copy All non-conflicting changes" functionality 
stopped working for you?
I'm asking because I didn't changed anything in that area for months, but I know that lots of text 
infrastructure changed underneath.

After performing a "Copy All non-conflicting changes", does the Compare Editor already shows the 
incorrect result, or is the incorrect result only stored to disk?
Comment 7 Frederic Fusier CLA 2004-04-30 04:45:56 EDT
1) Yes, this functionality stopped to work in build I200404270800 I installed 
last Wednesday and is still broken in last integration build I200404281424 I 
insatlled after. By the way, it works in integration build I200404220800 I used 
last week.
So something broke this functionality between last week and this week...

2) I'm not really sure what you mean by incorrect result... but when I push 
on "Copy all non-conflicting..." button, then the content of the right side 
content of the Compare editor is completely replaced by the left side content.

This means that after having pushing on the button, I there's no longer any 
difference in Compare editor between two sides although it should leave the 
outgoing ones. So, it's not necessary to save it to get the problem...
Comment 8 Andre Weinand CLA 2004-04-30 05:01:00 EDT
Two addition questions:

- can you reproduce this problem when working on HEAD (no branching, just accepting all incoming
  changes but leaving alone the outgoing changes)?

- can you send me a screenshot of the full workbench window after you pressed the
   "Copy All non-conflicting changes" button.

Thanks.
Comment 9 Andre Weinand CLA 2004-04-30 05:21:02 EDT
Two more questions :-)

- what VM are you using?

- can you reproduce the problem when working on the whole CU as opposed to working on a type or 
just a method? That is, does the problem still occur even if you are not selecting anything in the 
structure compare pane (top right pane).
Comment 10 Frederic Fusier CLA 2004-04-30 06:00:49 EDT
Two more answers ;)
1) Here's the VM I use:
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)

2) Yes, as I said in comment 3, it happens both when I select whole CU or only 
a method in structure compare. In fact I would say this happen whatever you 
select in structure compare pane but it is only visible when there's outgoing 
changes (conflicting or not) for the selected Java element...

It seems obvious because when there's only incoming changes, replace left side 
with right side does not matter...
Comment 11 Frederic Fusier CLA 2004-04-30 06:10:33 EDT
Sorry, I missed your questions in comment 9.
I'm launching merge process and should be able to answer you soon...
Comment 12 Frederic Fusier CLA 2004-04-30 06:33:31 EDT
Comment 9, question 1):
Yes, the problem also happens while synchronizing workspace with HEAD (ie. 
merge is not necessary to get it...)

I made two snapshots on this HEAD synchronization which has some conflict:
1- before to push on "Copy All Non Conflicting..." button
2- after having pushed on this button

I'll now attach them to this bug...
Comment 13 Frederic Fusier CLA 2004-04-30 06:34:49 EDT
Created attachment 10160 [details]
Snapshot of synchronize view before to push on "Copy All..." button
Comment 14 Frederic Fusier CLA 2004-04-30 06:35:41 EDT
Created attachment 10161 [details]
Snapshot of synchronize view AFTER having pushed on "Copy All..." button
Comment 15 Andre Weinand CLA 2004-04-30 06:45:58 EDT
Due to a bug in platform.core (bug #60172) Compare's preferences are not initialized correctly.
As a consequence, synchronized scrolling is turned off (as I noticed in your screenshot).

Does it make a difference if you turn it on via the Compare/Patch preference page:
goto tab "Text Compare" and turn on both the "Synchronized Scrolling..." and "Connect ranges with a 
single line" options and the press "Apply".
Comment 16 Frederic Fusier CLA 2004-04-30 06:53:13 EDT
Yes! :)) That's it.

Turning ON these two Text Compare preferences make this functionality work well 
back.

I do not see really the relation between these preferences and why outgoing 
changes are removed while copying all non conflicting changes but the important 
thing is that I have a workaround :))

Thanks a lot...
Comment 17 Andre Weinand CLA 2004-04-30 07:04:51 EDT
That's good news,
so would it be OK for you to lower the Severity to "mayor" (since a workaround exists)?

Thanks for your help!
Comment 18 Frederic Fusier CLA 2004-04-30 07:51:29 EDT
Agree to lower the severity to major...
Comment 19 Andre Weinand CLA 2004-04-30 18:01:20 EDT
Fixed for N20040501
Comment 20 Christof Marti CLA 2004-05-19 11:08:46 EDT
start verifying