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.
Hi Tony, > > > So I would like to know which settings are responsible to determine > > the locales on both machines. > > It's irrelevant really (provided the characters are common to both > machines - you'll get an error if not)... as long as both client and > server are on 2.0.58 then things should work. This is the problem - on the linux server (gentoo linux) the 'normal' cvs is running, not cvsnt. That explains why -o had no effect. And it is not irrelevant in my situation, because the cvs server will handle linux clients (configured with unicode) and windows clients. I can discourage the use of Umlaute in file names, going back to plain old ASCII. Let me summarize (I am still unhappy with the situation): Using :ssh: from Linux to Linux works, both using Unicode. Windows XP is using Unicode, but WinXP to Linux is not working. Both variants are using ssh. The Windows client is using PuTTY, which works as terminal in Unicode. Why can't I configure cvsnt to work completely in Unicode? Dietrich P.S. look like i am spending my working time on this issue ;-) "Tony Hoyle" <tmh at nodomain.org> wrote in message news:cn8ms8$gog$1 at paris.nodomain.org... > Dietrich Schmidt wrote: >> Hm, I did it - but it does not work :-( >> >> I installed cvsnt-2.0.58d.exe, which works fine but does not translate >> locales in the filename: >> >> Unicode filename with umlaute on server gives (using cmd.exe) >> >> C:\cvsroot>cvs -o update Playground >> cvs update: Updating Playground >> cvs update: warning: Playground/FromPutty+¦+ñ+++û+ä+£+f.txt was lost >> U Playground/FromPutty+¦+ñ+++û+ä+£+f.txt > > If you've previously had corrupted names that's just it fixing itself. > >> C:\cvsroot>cvs -o update Playground >> cvs update: Updating Playground >> cvs update: warning: Playground/Umlaute??÷????.txt was lost >> U Playground/Umlaute??÷????.txt >> >> which is displayed correctly on Windows but as garbage on Linux. >> Why are the Umlaute scrambled in cmd.exe? > > Not sure what you mean there - you just updated it in Windows and it > displays correctly... Linux is irrelevant at that point (presumably the > RCS files have the correct names, if they don't then you should either > rename them manually on the server, or delete and re-add them). > > cmd.exe sometimes doesn't handle ansi properly. Look at it in Explorer > and it'll be fine (seems to be random, and is a cmd.exe bug I think). > >> So I would like to know which settings are responsible to determine >> the locales on both machines. > > It's irrelevant really (provided the characters are common to both > machines - you'll get an error if not)... as long as both client and > server are on 2.0.58 then things should work. > > As a test you can try checking out the 2_0_x branch of the cvsnt > repository - there's a file in the root that has umlauts in it, which will > only come out correctly on 2.0.58 with -o (or 2.0.6x when working). > > Tony