Community
Participate
Working Groups
I've been using Eclipse for a while(since 2.0) and I've always struggled with getting Eclipse to ignore differenes in whitespace when comparing. There should be a much more obvious way to tell Eclipse to ignore whitespace during compare that *works*. See attached picture for an example. Øyvind
Created attachment 14565 [details] Shows ignore whitespace checked, but compare still shows area as differing...
The attached picture shows a conflict. Without seeing the ancestor, it is impossible to learn anything about whitespace.
>The attached picture shows a conflict. Without seeing the ancestor, it is >impossible to learn anything about whitespace. I don't understand what you mean, could you clarify? I see lines that do not differ at all(possibly in whitespace) that are marked as "conflicting"(i.e. red). This is a mystery to me. Øyvind
Please open the third ancestor pane. It'll show the reason why you have a conflict. You can open the ancestor with the left most button in the Text Compare's local toolbar.
Created attachment 16488 [details] The treenode should not be created when ignore whitespace is turned If only whitespace differs, do not create the tree node in the compare view, team synchronize, etc.
I'd like to request that the priority of this one is bumped...
Can you provide a set of steps to reproduce the problem you are seeing (i.e. ignore whitespace works for me)? It would also be helpful if you could provide 2 (or three if necessary) file versions to reproduce the problem.
(In reply to comment #7) > Can you provide a set of steps to reproduce the problem you are seeing (i.e. > ignore whitespace works for me)? It would also be helpful if you could provide > 2 (or three if necessary) file versions to reproduce the problem. After some investigations it turns out that things have improved dramatically from 3.2 to 3.3 in this regard. The actual file compare seems to work, but I need to double check that the structure compare does not show false positives when ignore white space + consider file contents is enabled.
The only remaining problem in 3.3 is that the structure compare does not take file contents into account. I.e. if there is a file that *only* differs in whitespace changes, it is still shown in the team->synchronize view as differing. When double clicking on that file no differences are shown. To reproduce: 1. Turn on ignore whitespace 2. Turn on consider file contents 3. Add a newline to the end of a text file 4. Run team->synchronize, the text file in (3) is shown as a changed. This becomes a real problem when different text editors is fighting over what sort of newline to use(dos or Linux) as may be the case when using e.g. FPGA(eletronics/hardware) tools together with Eclipse.
The issue you mention is specific to CVS and is intended behavior. CVS does not have an option to ignore whitespace when committing so we need to show files that contain whitespace changes as outgoing changes (i.e. how can CVS differentiate the false changes you mention from intended changes). I'm marking this as worksforme since, from a Compare component standpoint, this issue appears to be resolved. Having said that, I could envision a CVS feature that ignored line ending changes on commit (and hence, in the synchronize view). However, we don't have the cycles to work on such a feature. If you wanted to contribute a such a feature, we would be willing to accept a contribution.
(In reply to comment #10) > The issue you mention is specific to CVS and is intended behavior. CVS does not > have an option to ignore whitespace when committing so we need to show files > that contain whitespace changes as outgoing changes (i.e. how can CVS > differentiate the false changes you mention from intended changes). I'm marking > this as worksforme since, from a Compare component standpoint, this issue > appears to be resolved. > > Having said that, I could envision a CVS feature that ignored line ending > changes on commit (and hence, in the synchronize view). However, we don't have > the cycles to work on such a feature. If you wanted to contribute a such a > feature, we would be willing to accept a contribution. This applies to Compare with -> Eachother, CVS is not involved.
Sorry about that. For Compare with Each Other, I agree that the issue mentioned in comment 9 is relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
