Summary: | Copy All non-conflicting changes from right-to-left erase left-to-right changes!!! | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Frederic Fusier <frederic_fusier> | ||||||
Component: | Compare | Assignee: | Andre Weinand <andre_weinand> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | major | ||||||||
Priority: | P2 | CC: | michael.dillon, Michael.Valenta, pascal | ||||||
Version: | 3.0 | ||||||||
Target Milestone: | 3.0 M9 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows 2000 | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Frederic Fusier
2004-04-29 04:57:13 EDT
This button in provided by the Compare component. 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. 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? I tested using the latest compare/team/cvs from HEAD. 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 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? 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... 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. 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). 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... Sorry, I missed your questions in comment 9. I'm launching merge process and should be able to answer you soon... 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... Created attachment 10160 [details]
Snapshot of synchronize view before to push on "Copy All..." button
Created attachment 10161 [details]
Snapshot of synchronize view AFTER having pushed on "Copy All..." button
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". 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... 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! Agree to lower the severity to major... Fixed for N20040501 start verifying |