Text file encoding problems between Linux and Windows Eclipse Clients
I recently received a computer upgrade which was loaded with the RHEL6 Open Client. My previous machine was loaded with Windows XP. I installed RTC Eclipse Client 3.0.1.3 to develop plug-ins for my Jazz Team Server. I created a repository workspace and loaded it from a stream on a CSNext server which is the Jazz Team Server containing our code library. After loading the workspace, the projects did not build because the java files could not be opened. When I tried to open them in the java editor, I got an error indicating the files could not be opened with UTF-8 encoding. I opened the project properties editor and saw that the text file encoding property was set to "Inherited from the container (UTF-8)". I then opened the project properties editor for the same project in the RTC Eclipse Client on my Windows machine and saw that the text file encoding property was set to "Inherited from the container (CP1252)". I assume this is because the projects were originally created on a Windows machine.
Before changing all of our files in the CS Next RTC SCM, I would like to know what the suggested approach is when loading files from the SCM onto multiple platforms. Would it be worth opening a feature request to enhance the process of loading from a stream such that files stored in one format be converted to a format suitable for the client?
Before changing all of our files in the CS Next RTC SCM, I would like to know what the suggested approach is when loading files from the SCM onto multiple platforms. Would it be worth opening a feature request to enhance the process of loading from a stream such that files stored in one format be converted to a format suitable for the client?
2 answers
Sadly, this is a known problem. RTC doesn't do anything prescriptive about encodings, so the user can create a project which has encodings that aren't available on other machines. Having said that, I can't find a work item that explicit mentions it, so feel free to create one.
As to the solution: switching the encoding on the source machine should be fairly painless. If you close any open change sets, you can easily discard back to your current state without losing any work.