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.
I would like to start by saying that i know this is bad tradition, but we have files/directories which includes non-us-ascii chars in their name in our repositories. These files/directories handled correctly by previous versions of cvsnt. (we have Windows codepage 1250 on clients and server, too) We could correctly use import, add, update, commit, etc. commands. I always test new versions of cvsnt on my workstation before install in production environment. Now install new 2.5.01.1894 cvsnt in production environment, because my tests were OK, and needed to install it, because in this version Tony fixed the filename passing to taginfo triggers. OK, now we can log the tagging operations correctly, but we cannot work with our files/directories which includes non-us-ascii chars in their name! These operation ran correctly in our test environment on my workstation, but now fails on the remote cvs machine. Why? If we can import such file/directory to our remote repository (sometimes we can), we cannot check it out! (cvsnt change the codepage of the name of the file/directory! Why? server and client codepage is the same.) We cannot checkout our good old files and directories with non-us-ascii chars in their name! Why? I'm very annoyed, because I tested it previously. So cvsnt works good if client and server on same machine, but works incorrectly, if server is on another machine. It's seems, we must step back to last good version: 2.0.58d. I think, we cannot call this new version of cvsnt "Release Candidate", this is a serious bug! Sorry to say, but this is unusable for us. and don't say about msi install... Zoltan