Files lose their encoding after manual merge

[marioo]

Seems that the error you once corrected is back. When a file requires a manual merge, it loses its encoding.

 

Steps to reproduce the error:

1. Create a UTF-8 encoded text file in your workspace (I do it using Notepad++) and check it in.

2. Modify it in the main branch and in a child branch so that when merging the branches later on, a manual merge is required.

3. Merge the child branch into main (a manual merge is expected to be needed here).

4. Check the changes in.

5. Now see the file in your workspace. When you open it in Notepad++, it will indicate ANSI encoding instead of the original one (UTF8).

 

Let me note that we currently use Plastic SCM 5.4.16.680 - Luxor, and the Default encoding and Result encoding preferences are both set to None. What's more, during the manual merge all files are shown to be UTF-8 encoded (base, source, destination, result). 

 

Plastic SCM 5.4.16.671 works fine as far as said issue is concerned.

 

See attached the two archives with files before and after merge. I performed tests with two UTF8-encoded files, but one of them initially had BOM bytes, and the other had not. After a merge both of them had no BOM bytes, and ANSI encoding was assumed by Notepad++.

UTF8 with BOM before merge, no BOM after merge.zip

UTF8 with no BOM before merge, ANSI after merge.zip

[manu]

Hi Marioo,

 

i'm sorry but I can't reproduce the issue. I'm testing it with the "5.4.16.681" release. Can you retry with my release?

[marioo]

Hi Manu,

 

It seems that you already corrected the bug in the version you were testing. I've just found the following entry in your change log (5.4.16.681): Merge Tool: The encoding is not taken into account when the result file is saved. Fixed. So I guess we can consider this topic as closed.

 

Thanks!

[manu]

Great!