Community
Participate
Working Groups
Using M5, in a merge process, when I move from right to left, the text is misplaced and it is not possible to get a structure compare anymore. The text is inserted before the beginning of the top level type. This makes a merge operation really painful.
Cannot reproduce in M5. Olivier, can you give me more detailed steps? Thanks.
I cannot give you a specific test case. The problem occurs when I merge the HEAD stream into the JDK_1_5 branch. When HEAD contains a method addition and I click that button to move it to the left panel, it always end up misplaced. Try to put a comment before the top level type. I don't know how to help you more on this one. If only I could create such a compare view without CVS, I could try to isolate a test case.
Aha, it's a "method addition", so you have a method on the right hand side and the left hand side is empty? I'll try to reproduce this. In the meantime a workaround might be to select the container of the method (so that the left-hand side is not empty), and move the method then.
Yes!!! :-) This describes exactly what happened. The left side is empty and I see the method addition on the right side. Clicking on the left arrow to move from right to left ends up with a compilation unit that cannot compile or parse and the compare doesn't work anymore, because the structure cannot be retrieved.
*** Bug 55066 has been marked as a duplicate of this bug. ***
I have exact steps to reproduce. - open a compare with revision dialog on /org.eclipse.platform/src/org/eclipse/core/launcher/Main.java with revision 1.51 in your workspace and revision 1.49.2.1 from the server. - in the structure view, click on the PROP_LOGFILE deletion such that it is the only thing that shows up in the text panes below (left empty, right with the field decl) - Select "Copy current change from left to right" - note that the left pane is still empty. - select the compilation unit and scroll down so the field appears in the right pane. - note that in the left pane the field has been inserted but another field EOF has been removed. This is one example. I have seen others where the copied changes were moved into random spots without any way of noticing. On doing a number of these I ended up with a completely hosed workspace and basically had to start again. This has the potential to waste alot of time and in fact insert bugs if the erroneous changes to not cause compile errors etc (i.e., they go unnoticed) If the problem cannot be fixed, the function shoud be disabled.
this is still a problem in i0326-0800.
The workaround is described in comment #3. A fix will be provided after my vacation (after M9).
*** Bug 49391 has been marked as a duplicate of this bug. ***
I'm not sure this is critical. This feature has never worked since 1.0.
How can it not be critical? It silently introduces errors (not necessarily compile errors) into your code? If it has never worked then no one will mind that it is disabled?
It is critical, and I'm fixing it.
Jeff, by "never worked" I don't mean that this action was disabled in version 1.0, I meant that this bug has *existed* since 1.0. See bug 11375 and its dupes. In the past this problem has been marked as "normal", and it has been in 3 releases already? That was my point, but I think it's great if it finally fixed for 3.0.
Wow, this reverse psychology stuff works great! Um...I mean, it doesn't work at all.
Since it is difficult to find an insertion spot based on the structure compare alone (which results in the problems described in this bug), I did the following: whenever the structure compare shows additions or deletions, I'm no longer feeding the deleted or added object in one pane of the compare viewer and leave the other empty. Instead I show the parent object of the deletion or addition and reveal the first diff that overlaps with the added or deleted object. The benefits are twofold: the insertion spot determined by a textual compare is much closer to what you would expect and there are no surprises because the insertion spot is shown within its container before text gets added or deleted.
in 0611 There are still problems in this area. In the ottcvs1/home/cvs/corerepo look for org.eclipse.core.tools and compare revision 1.1 of MANIFEST.MF to revision 1.2. When I did this I had a conflict (I had 1.1 and deleted the line org.eclipse.core.tools.resources but not released). When I selected the conflict and clicked move right to left, I got the new text (from 1.2) duplicated in the left side. Like some of the other scenarios, this did not result in syntax errors but did result in a wholy invalid file.
not for 3.0
bugzilla hosed me - my comment was for a different defect report.
Re 16#: This is the correct behavior. If you have a conflict and use the "Copy from to" buttons the text on one side is not replaced but the other side is added. See bug #5323. Please add comments there and/or reopen #5323.
fixed for I20040610
re comment 19, this if very strange and seems inconsistent. In the cases I have seen, it results in a garbled mess that it hard to detangle. I could not see any particular logic in where the right hand text was inserted in to the left hand side. As a result, it took me several tries to detangle. Each time I either cut out too much or too little to get the correct end result. In the end i would have been better off just retyping or manually cutting and pasting. I suggest that the copy operation have consistent behaviour. The merge currently offered does not seem to add value (i..e, it is not able to do a smart merge) so people needing to merge should copy and paste as needed.
Can you provide a screenshot?
steps to reproduce are in comment 16.
Comment #16 uses a MANIFEST.MF file, which is not associated with a Java properties merge viewer. As a consequence you won't get a structure compare, but just a plain text compare viewer (with the behavior described in #5323). If you see problems when restoring deleted properties (in a Java properties file), please see re-opened bug #34745. It is scheduled to be fixed for one of today's later builds.
It doesn't really matter what kind of merge view is being used under the covers. This is still a problem.
The original problem described in #3 and #6 occured on restored deletions. This has been fixed as explained in comment #15 and specifically for property files with a fix for #34745. Please verify this fix in a build that includes a fix for #34745 too. The problem of comment #16 must be a different problem, because there is no structure compare available for *.MF files. So please open a new bug for that problem with detailed steps and icnlude a screen shot. I cannot reproduce the problem of comment #16.
*** Bug 11375 has been marked as a duplicate of this bug. ***
