[cvsnt] Re: Filename mapping problem

Tony Hoyle tony.hoyle at march-hare.com
Tue Oct 11 02:33:58 BST 2005


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.


Torsten Martinsen wrote:
> Server: CVSNT 2.5.02.2083 (Linux)
> Client: CVSNT 2.5.01.2025 (Windows XP)
>  
> When updating a module containing a filename with a 'ü' character, I get the message "Characters from server lost in translation" and the file is created with the ü character missing.
>  
> Can something be tweaked to at least allow filenames using ISO-8859-1 characters to work properly?
>  
>
Only by putting the client into something that's compatible with 
ISO-8859-1 (CP1252 is compatible for example)...  The CVSNT client is 
still largely ANSI (2.6.x is almost all Unicode except for the command 
line interface, but that doesn't help you at the moment of course), so 
is rather stuck with the current ANSI codepage for most operations. 
Most people don't notice the problem because their servers and clients 
share codepages.

You can actually force the client into UTF8 with the --utf8 flag 
(although that'll put all your CVS/Entries files in utf8 too so it's not 
so useful for general use).  That works with any filename... OTOH I'm 
not sure how reliable build 2025 is with that.

The other possibility is the server is in something like 7-bit ASCII and 
the filenames it's sending are invalid (because they contain 8 bit 
characters).  Solaris has this problem by default, although it's easy to 
workaround by setting LANG=en_US.ISO8859-1

You can check what codepages are in use by doing something like
'cvs -ttt ver' on the sandbox.. the codepage is in the first few lines 
of output.

Tony



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook