Moving a CVS repository from a Linux server to CVSNT
This has been asked a number of times so here is a rundown on what needs to be done in order to have all of the original revisions available also on the new platform.
On Linux TAR up the entire directory tree starting from the cvs repository top. You don't need the CVSROOT directory because the admin file contents will be different anyway on CVSNT. You can save the CVSROOT/history file from the original repository if you want to use the history command and have it show also the old events.
Move/copy the TAR archive over to the CVSNT server PC.
In CVSNT control panel go to the Repositories tab and add a new repository. Navigate to a suitable place on the CVSNT server where you want the Linux repo to be located. Let CVSNT initialize the repository. Stop and Start the CVSNT service.
Open the TAR file in Winzip and go to the tab Options/Configuration/Miscellaneous. Make sure to UNCHECK the item 'TAR file smart CR/LF conversion'! Failing this will corrupt the repository! I think that this Winzip option is not really so "smart".
Extract all module folders and files into the newly created CVSNT repository while preserving the folder structure (check "Use folder names" in Winzip).
Now you are basically done and your Linux repository should be accessible via the CVSNT server including all past revisions!
You will note that the history is now gone, since it is stored inside the CVSROOT folder, which was not TARed. If you like you can simply copy this file over from the Linux repository into the CVSNT CVSROOT folder but it is not essential for CVS operations so it is your call if you want this. If so you should do this before you start using the repository, because as soon as you do CVSNT will start building its own history file.
A few additional concerns (from posts by Bo Berglund, Arthur Barrett and Andreas Tscharner to the CVSNT support group between 2007-08-31 and 2007-09-03, with some editing):
Line endings: The CVS/CVSNT repository files are all using UNIX line endings. If you let some tool convert these then the system will fail miserably. They must stay with LF as the line endings.
One-way street: You will have some issues, but not many going from CVS to CVSNT -- but it is a one-way street. Once you start working on the repository in CVSNT it cannot be moved back to GNU CVS.
CVSROOT directory: Most of the necessary adaptation work is in the CVSROOT files and the best advice I can give is to not copy over CVSROOT. Instead, create a new repository on the new server using the latest version of CVSNT. Then copy in the repository files from the Linux repository to this new repository (creating a tree structure equal to the one on the old server) and set up your CVSROOT scripts as you would like them to work on Windows (using the scripts of the old server as a starting point, but not copying them verbatim).
Links on UNIX: CVSNT on Windows cannot cope with links. You have to create file copies if you have the repository on Linux set up with linked files (which in my opinion do not belong inside a repository at all).
Linux permissions/execute bit: Old CVS 1.11 determines what "permissions" to give a checked out file (eg: 666, 755 etc) based on the permissions on the RCS file. This works fine on Linux/Unix, but does not translate onto Windows. The only "bit" that usually matters is the execute bit. Find all the RCS files in the repository with the execute bit set and after you complete the migration to CVSNT on Windows then checkout the file onto Linux/Unix from the Windows repository, change the "mode" (chmod 755 file.ext) and then force commit it (cvs commit -f -m "") to store the "mode" "execute bit" "permissions" in the file. Note: "permissions" is a really overloaded term nowadays with ACLs and "execute bit" both easy to confuse with this... (Of course if no RCS file in the 1.11 repository has the execute bit set then all that is unnecessary.)
Case sensitive file system: On Linux Example.c, example.c and eXampLe.c are three different files (and can appear in the same directory), on Windows these three files are identical and may cause problems.