Community
Participate
Working Groups
When syncing a file with conflicts, and clicking "Copy All Non-Conflicting changes from Right to Left", all of the local changes are lost. The current behaviour is similar to that of Overwrite and Update. Previously this function would copy all all non-conflicting inbound changes only.
Me too.
I don't think you are really using 4.8? Please provide Eclipse version where you see the problem. I believe this was already fixed in 4.6.3 and 4.7.0, so please test the latest released version.
Sorry, I did not notice the version number written on this page before. My Version is Oxygen Release (4.7.0) Build id: 20170620-1800
Sorry, yes I'm using Oxygen Release (4.7.0), Build id: 20170620-1800
Checked for updates and there were none, so I'm still using build previously mentioned. Retested and local changes are lost upon clicking the button. To test: 1. Select a non-modified object. 2. look at history, and get a previous revision. 3. Make a change to the object and save. 4. Synchronize the object with the repository. 5. In the compare, click the "Copy All Non-Conflicting Changes from Right to Left". Upon completing step 5, the changes from step 3 are lost.
Can it be that all who observe this bug are using SVN? Is there anyone using Git and observing this problem?
I'm certainly using SVN (actually subclipse).
Our team is also seeing this while using 4.7/Oxygen. We are comparing Java files that are stored in RTC.
This would be a blocker for IBM RTC, we can't ship our source control product on top of this due to the risk of losing work and or unintentionally performing bad merges when accepting changes from source control. The problem goes away if I hack my install to use org.eclipse.compare_3.7.1.v20170103-1805.jar instead of org.eclipse.compare_3.7.100.v20170303-1847.jar
Just to add to the previous 2 comments, this is a stop ship for claiming support for Eclipse 4.7 from an IBM Team Concert product perspective. The severity of this work item is a Blocker in my opinion but I am not permitted to adjust the issue severity. We are hoping to be able to claim support for Eclipse 4.7.1 when we ship the next release of RTC this fall but will only be able to do so if this issue is addressed in 4.7.1. The steps to reproduce in vanilla Eclipse are: 1. Create a file named ancestor.txt in an Eclipse project that contains the lines: 1 2 3 2. Create a file named right.txt in an Eclipse project that contains the lines: 0 1 2 3 3. Create a file named left.txt in an Eclipse project that contains the lines: 1 2 3 4 4. Select the 3 files and choose Compare With/Each Other from the context menu. Ensure that ancestor.txt is selected as the ancestor 5. Click on the Copy all Non-Conflicting Changes from Right To Left toolbar button and notice that the "Left to Right" change is removed. This causes a loss of data which makes it a blocker.
This is pretty ugly! Andrey, I didn't verify this and it's just a shot into the dark, but bug 512395 might be related. Can you please check? Thanks.
(In reply to Dani Megert from comment #11) > This is pretty ugly! > > Andrey, I didn't verify this and it's just a shot into the dark, but bug > 512395 might be related. Can you please check? Thanks. I'm investigating, looks like this is the root cause.
(In reply to Andrey Loskutov from comment #12) > (In reply to Dani Megert from comment #11) > > This is pretty ugly! > > > > Andrey, I didn't verify this and it's just a shot into the dark, but bug > > 512395 might be related. Can you please check? Thanks. > > I'm investigating, looks like this is the root cause. The assumption in bug 512395 comment 0 was wrong, we can't just use same code as in copyDiffRightToLeft(), exact because we want keep the left side changes if parent/right were same. It was my fault to assume that the "apply current change" for *all* changes one by one and "apply all non conflicting" should have same effect. This is not the case, "apply current" is always implicitly in "override" mode, "apply all" is not. So we can't implement the fix for bug 512395 without breaking the existing 3 way compare behavior. I will reopen bug 512395 and revert changes, see https://git.eclipse.org/r/101804 for 4.8. Backport to 4.7.1 will follow soon.
New Gerrit change created: https://git.eclipse.org/r/101808
Gerrit change https://git.eclipse.org/r/101808 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=350ed4cfed5cbfd54124d22d95a2dc0bbd113c88
Thanks Andrey!
*** Bug 520642 has been marked as a duplicate of this bug. ***
Eclipse IDE for RCP and RAP Developers (includes Incubating components) Version: 2020-06 (4.16.0) Build id: 20200615-1200 When I comparing two files(right.txt and left.txt) and use "Copy All Non-Conflicting changes from Right to Left", all of the changes in left.txt file are lost, it just overwrite changes in left.txt from right.txt. I think this issue need to be reopen. I'm attaching video for your reference. Can you please check? Thanks.
Created attachment 288091 [details] "Copy All Non-Conflicting changes from Right to Left" overwrites changes
(In reply to Vivek Bugale from comment #18) > When I comparing two files(right.txt and left.txt) and use "Copy All > Non-Conflicting changes from Right to Left", all of the changes in left.txt > file are lost, it just overwrite changes in left.txt from right.txt. I think > this issue need to be reopen. > > I'm attaching video for your reference. > > Can you please check? Thanks. The concept of "non conflicting changes" makes sense when you have a 3-way comparison. In this context, "non-conflicting changes" are those changes made on the right ride starting from the common base (i.e. common to the left and the right) which can be applied on the left side because they do not conflict with any other changes made on the left but not on the right. A common example is the "Edit conflicts" use case. This bug report was about this, that is the 3-way comparison was not distinguishing any more between actual changes on the right vs "other changes" (made on the left, but not correlated with the change set you were merging). When you just make a simple comparison between two files, "Copy All Non-Conflicting changes from Right to Left" becomes a "copy all differences from right to left", because there's no base reference that can be used to determine which changes were made just on the right side vs "other changes" (made just on the left side). What would you expect the "Copy All Non-Conflicting changes from Right to Left" action to do in a simple 2-way comparison?
