Community
Participate
Working Groups
Build ID: M20080221-1800 Steps To Reproduce: Pre-requisites: - done on Windows - the class file is in UNIX format (ie. LF vs CRLF) in SVN repository 1. Do some changes to a Java class 2. From Synchronize view: "Local-Create patch" 3. Revert changes for whatever reason 4. From "Package Explorer" view: "Team-Apply patch" 5. From Synchronize view: "Open in Compare Editor" => all lines are tagged as modified, because the end of line characters was changed on every line, along with the actual changes! More information: Before step 5., ensure that "Ignore white space" in "Window-Preferences-General-Compare/Patch" is _disabled_, to see all lines as changed. In summary, instead of favoring the EOL char in effect in the patch, and to apply it to the _whole_ targeted file, it is expected that the EOL character of the target file would be favored, and that all lines not mentioned in the patch remain untouched. BTW, this is the behavior of the embedded CVS plugin for this operation.
Quoting myself: "In summary, instead of favoring the EOL char in effect in the patch," Actually, I just figured out that this is independent of the patch format. Indeed, since a while, I changed the "Prefs-General-Workspace-New text file line delimiter" setting to "Unix", consequently patches are now generated with LF EOL. However, "Apply Patch" systematically transforms the whole file with CRLF EOL! And this is the case even if the file has the property svn:eol-style set to LF... This is really a problematic issue. Unfortunately there was no feedback since issue opening...
Thanks for your investigations. We've just checked our patch format, and found that the line separators are correct. But you are quite right, after applying it they are changed to a system default ones. But I must admit that the "apply patch" functional is the Eclipse IDE one. So we'll check once more, if there is anything we can do.
(In reply to comment #2) > But you are quite right, after applying it they are changed to a system default > ones. But I must admit that the "apply patch" functional is the Eclipse IDE > one. That was what I thought once, then I realized that when working with CVS and the embedded plugin, I didn't get this behavior, hence the creation of this bug report > So we'll check once more, if there is anything we can do. OK, thanks in advance
We've checked the situation once again with the CVS plug-in in the Eclipse 3.3.2 environment. In our test case the completely new file which have only LF EOLs is included into the patch, then removed from the project then returned back using Apply Patch wizard. The file size is grown up to 36 bytes from the original 29 bytes size. So, we are concluded that the problem is related to Apply Patch wizard and not to Subversive. P.S. Moving this issue to Platform:Team in order to collect opinions about what is going wrong when a patch is applied.
(In reply to comment #4) Thanks Alexander for having investigated again, though I'm a bit puzzled by what you got with the CVS plugin... Indeed, as already noticed, I used to use it regularly before Subversive, applying patches with changes on files already existing in project, and didn't face such a behavior. (IOW, my usage was a bit different that your latest test, though one could expect that behavior should be the same...) Well, hope that the Platform team will be able to shed some light on this odd issue...
*** This bug has been marked as a duplicate of bug 150591 ***
