Description Oliver Büechi 2010-09-13 10:52:42 EDT

Build Identifier: Helios Release v20100617-1415, Subversive v0.7.9.I20100512-1900

We have a Java project, with ISO-8859-1 encoding as default. Almost all source files (mostly *.java) inherit that encoding from the project. Some *.xml files are UTF-8 though (encoding is set as Eclipse file property as well as in the file header), and these UTF-8 files have a problem when merging.
To be more exact:
- If Subversive is able to merge the changes automatically, everything works fine (I can approve the auto-merge and check in).
- But if Subversive cannot auto-merge two files, the user is asked to merge the file manually, and that's when the encoding problem occurs.

Let's assume I'd like to merge the revision 33578 of a file called jet-resources.xml from a branch to the trunk, and Subversive cannot merge it automatically, so I will have to resolve the conflicts manaully. What happens is that three additional versions of the file are created automatically:
- jet-resources.xml.merge-left.r33577
- jet-resources.xml.merge-right.33578
- jet-resources.xml.working

The "Edit Conflicts" editor will display the "working" file to the left, and the "merge-right" file on the right. The "working" file on the left looks OK, with all special characters intact (for example "ü"). The "merge-right" file on the right however is displayed with ISO-8859-1 encoding (project default), so all special characters are "garbled". The "ü" character is displayed as "Ã" for example.

As the file in question is pretty large (26+k lines) and each of the mis-interpreted characters show up as a change, there are hundreds of fake conflicts. Needless to say that going through all of these fake changes just to find the few lines that I'd actually like to merge is time consuming and frustrating.

The problem seems to be that Subversive (or Eclipse itself?) uses the project's default encoding (inherited from container: ISO-8859-1) for the three temporary files, rather than the original file's custom encoding (Determined from content: UTF-8).

I would expect Subversive to use the same encoding for the temporary files as for the original file, and strangely enough, it already partially does. Remember that jet-resources.xml.working displays ISO-8859-1 encoding in its properties. Consequently, if I open the file in the XML or text editor by double clicking, the special characters are garbled. However, all of its special characters do show up correctly in the "Edit Conflicts" editor, so clearly this conflict editor uses a different encoding to display the file on the left!

If only it would use the correct encoding to display the content of the jet-resources.xml.merge-right.33578 as well. At the moment it does not, it uses the project's default encoding. I verified this by temporarily setting the project default to UTF-8, and retrying the merge. When I did, it worked. This is not a feasible workaround though, since most files do need to be ISO-8859-1.

Reproducible: Always

Steps to Reproduce:
1. Have a project with some default encoding, let's say ISO-8859-1
2. Have an XML file with a different encoding, let's say UTF-8. It should contain some special characters, for example vowels with umlauts, such as ä, ö and ü.
3. Merge a single revision's changes in this XML file from one branch to another. The change must be so complicated that Subversive cannot automatically merge the file. Unfortunately I don't know exactly what makes it unable to auto-merge (maybe other changes must have happened on the file as well).
4. In the Synchronize View of the SVN Merge, right-click on the conflicted file and select "Edit Conflicts"
5. Behold that the special characters are displayed properly on the left side, but incorrectly on the right side