Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Richard Wirth wrote:
> Hello Tony,
>
> ...
>>> 1. CVSNT servers on unix try to run in UTF-8 if the system supports
>>> this.
>
> TH> Yes this has been true for a while. It's the only way to ensure a
> TH> common protocol - cvsnt clients then translate back to their local
> TH> codepage as required
> ...
> Is the translation done on server or on client side?
The client - only the client definately supports its local codepage (a
Linux server for example normally has no idea about Windows codepages).
> How to do that? Is there a tool/solution?
> This should be mentioned in the wiki ('moving a repository')...
AFAIK there's no tool, unless someone has written on. As it also
affects cvshome there's a chance there is one out there somewhere.
> Normaly the codepages can be guessed / are known for a particular
> repository, so a conversion should be possible (even it may be not
> 100% correct)
In theory - just never had the time to spend on it... it needs a basic
RCS parser and something to do the conversion.
>>> 3. If one overwrites the servers codepage via /etc/cvsnt/PServer
>>> clients running on the same machine as the server also get this
>>> codepage forced.
> ....
> TH> Shouldn't matter normally though - unix is quite good at handling
> TH> this stuff.
>
> How to understand this?
>
Unix supports UTF8 natively so if the client is running in it then
everything just works as normal - the user really doesn't need to care
about it. If cvsnt spawns vi for example it (should) inherit the
codepage of the client so the editing is done in the right codepage.
(the oddity is OSX, where the locale functions don't affect the file I/O
(which is always in UTF8) so you have to run in UTF8 always otherwise
stuff doesn't work).
Tony