Hello,
The option Encoding for non XML files from the Preferences is applied to all the files of the local working copy that are not associated with the internal XML editor of Syncro SVN Client, that is files that are not associated with the internal XML editor in Preferences -> SVN File Editors (for XML files the encoding is detected from the file content). There is no option in SVN clients or SVN servers for converting automatically the file content of files that are checked out or committed.
OK, this affects only the internal editor of Syncro SVN.
Are you sure a CVS client or a SVN client should change the content of a file that is checked out or committed? Some CVS clients allow changing the encoding of file names and commit comments on check out and commit operations but not the file content. What CVS client do you use?
We are using MacCVSX and WinCVS (both from
http://www.wincvs.org/).
These clients allow to define an encoding for text files. So the client converts the file while checkout and commit to the "correct native" encoding, which is not completely correct in all situation, but works for us since 10 years.
I'm not sure whether this concept is the right one, but, I think it should be an option in the Syncro SVN client to allow converting for a specified file type or to define user scripts which are executed.
We have nearly 200 different projects in our SVN repository and each of them has one or more .r resource script files containing the strings for the application. Because nearly all of these projects are crossplatform we won't use resource editors on each platform and enter all the strings on both platforms. So we use plain text files containing the strings which can be compiled on both platform (if they have the correct encoding for this platform).
I think it is not really neccessary to have an automatic file encoding on client side, but there should be the possibility to call a user defined script which does maybe the encoding or any other task while checkout or commit.
Thank you for answering my question.
At the moment it's a little bit frustrating using subversion. First we are running into problems regarding resource forks on MAC and now the encoding problem of some files.
Best regards
Bastian