CVSNT Installation for Windows

Introduction

Typical users of CVS do not need to read this page -- instead, the CVS overview is a more suitable page for CVS users.  System administrators who install CVS are also encouraged to read the CVS overview page.

See also Step by step installation of CVSNT

See also Creating a CVS Repository by Jeff Hunter

Questions? Post here.

Machine Requirements

CVSROOT Path Format on non-Windows Clients

WinCVS Daylight Savings Time (DST) Bug

CVS on Windows platforms has a bug during daylight savings time which causes client applications to think unchanged files have been modified.  For example, in WinCVS, the files are "red." See here.

SSH Clients for Windows

Setting Environment Variables on Windows

After modifying the SYSTEM path, you must reboot in order for the new path to affect system services (such as CVS).

Windows 95 / 98:

1. Modify c:\autoexec.bat and enter commands in the form of
   set variableName=value
2. Reboot

Close any open command-line prompts.  Go to the control panel.  Open System.  Click Environment.

Close any open command-line prompts.  Go to the control panel.  Open System.  Click Advanced.  Click Environment Variables...

Restricting Access to Sections of a Repository

Security Holes with PSERVER

First, passwords are transmitted in an easily reversible format.  Your passwords are not safe when using pserver unless you're using VPN.  Passwords aren't safe inside the firewall even when using VPN.

Finally, pserver transmits unencrypted packets.  This means that someone can see your source code with a packet sniffer.  If pserver is used over VPN, the packets will of course be encrypted over the VPN channel.

Repository Location

All CVS interaction occurs via the CVS NT Service.  The service allows source code to be managed in an environment that is independent of the clients that access it.  For example, when files are checked in, a message can be posted toa newsgroup (you can also send email instead).  Without the service, we would be at the mercy of clients installing special tools (e.g., Perl) that allow CVS to post messages to newsgroups.  The service is also significantly less likely to corrupt files and leave dangling file locks.

Reserved Checkouts

Client Installation

Installing the CVSNT Server

1. Perform "complete" install of CVSNT
2. Follow instructions here

Please note:

1. If you choose pserver, you need to create passwords for CVS users and add them to the passwd file in the CVSROOT module.  General CVS documentation covers this topic.  There are also some instructions in the FAQ below.
2. You can turn off pserver access because it represents a security risk.  Set the StartPServer registry setting to 0 (refer to the CVSNT readme) and restart the cvsnt service.
3. Do not use the CVS server machine for any purpose besides a CVS server.  All CVS access should be performed by remote machines.  More information...
4. Consult the CVS loginfo, taginfo, and notify page for installing change notifications

CVSWrappers and Binary Files

There is a special file in the CVSROOT module called cvswrappers.  One use for this file is to specify the file extensions for binary files.  cvs add and cvs import use this file to avoid mangling binary files when they are checked in.

1. Check out the CVSROOT module:
   cvs co CVSROOT
2. cd CVSROOT
3. Open cvswrappers in a text editor and paste in the following text:

4. *.cab -k 'b'
*.class -k 'b'
*.doc -k 'b'
*.dll -k 'b'
*.exe -k 'b'
*.exp -k 'b'
*.gif -k 'b'
*.gz -k 'b'
*.jar -k 'b'
*.jpg -k 'b'
*.jpeg -k 'b'
*.lib -k 'b'
*.msi -k 'b'
*.mso -k 'b'
*.pfw -k 'b'
*.png -k 'b'
*.ppt -k 'b'
*.sit -k 'b'
*.tar -k 'b'
*.tlb -k 'b'
*.vsd -k 'b'
*.xls -k 'b'
*.wmz -k 'b'
*.zip -k 'b'

5. Check in the file:
   cvs commit

Maintenance Tasks

On a periodic or nightly basis (especially before you tag files), you should...

1. Back up your raw repository files
2. Kill any 'dead' CVS processes on the server
   • Pick some time when CVS activity should not occur.  Sometimes this is not realistic so use your best judgment.
   • I don't see CVS processes hanging very much anymore so you can probably avoid this step
   • Run the following commands
     net stop cvs
rem wait 120 seconds for good measure
dgsleep 120
dgkill -f cvs
net start cvs
   • If you use impersonation, which is on by default for pserver and sspi, these commands should be run from an account with administrator privileges on the machine
   • If you don't use impersonation, these commands must be run under the user account that is running the CVSNT service which is the SYSTEM account by default.  If you use the SYSTEM account, the Windows Task Scheduler can not be used.  Instead, use "at" -
     at 00:00 /every:M,T,W,Th,F,S,Su cleanup.bat
See also here
3. Delete any 'dangling' CVS locks
   • The dangling locks issue no longer occurs with CVSNT 2.x.  Please see here.
   • Pick some time when CVS activity should not occur.  Sometimes this is not realistic so use your best judgment.
   • Dangling locks are files that start with a pound (#) or a comma (,)
   • Run the following commands on the CVS server using an NT user account that has write access to the repository files
   • dgdeletelocks path_to_raw_cvs_folder
dgdeletelocks path_to_cvs_lock_folder (optional)
   • If you use the LockDir option  (no longer necessary for CVSNT 2.x -- see here), the script dgdeletelocks should be run twice, once for the CVS repository folder and once for the lock folder
   • Run these commands after killing dead CVS processes as described above, after net stop and before net start
4. Clean out the temp directories on the server
   • This is no longer necessary in CVSNT build 62 and later
   • Get dgprune here
   • c:
   • cd \temp
   • dgprune .
   • cd \winnt\temp
   • dgprune .
   • Use the directory specified by the TEMP and TMP directories for the SYSTEM user (or the user that runs the CVSNT service)

How to Manage CVS Administrators

The CVS admin command usually results in the following error message:

cvs [admin aborted]: usage is restricted to repository administrators

There are two ways to set up CVSNT administrators.

(I) NT Security

Build 73 and later:

• If the user is authenticated via the domain, the user must have a "shadow" local user account on the CVS server that is the same name as the domain account.  The password doesn't matter.
• The user must be part of the local Administrators group, if the user is a local user on the CVS server, or if SystemAuth=no (see here).

Build 72 and prior:

• The user must be part of the Domain Admins domain group, if the user is authenticated via the domain
• The user must be part of the local Administrators group, if the user is a local user on the CVS server, or if SystemAuth=no (see here).

(II) CVSROOT/admin

In the CVSROOT folder on the CVS server, create a file named admin, which, like the passwd file, is not checked into CVS.  Each line in this file contains the "base" name (i.e., username, not domain\username) of each administrator.  If SystemAuth=no, the names are those that appear in the passwd file (see here).

CVS and CVSNT FAQ

How do I set up CVSROOT so it doesn't contain a drive letter?

This gives the administrator the flexibility to move repository files from one drive to another without affecting clients.

1. Set the "repository prefix" via the CVSNT control panel applet.  For example, you can set the prefix to c:\cvs and then use /cvs in CVSROOT which will be interpreted on the server as c:\cvs.
2. Another option is to put the CVS repository on the same drive on which the CVSNT server software was installed and use a path that starts with a forward slash, e.g.,
   :sspi:servername:/test

How do I browse the repository without checking out files?

• Use CVSWeb or ViewCVS
• Run cvs co -c to get a list of modules
• Run cvs -ls dirname to list the contents of any directory

• CVS and WinCVS can access raw repository files via the local protocol which is extremely dangerous and will result in corrupt files and dangling file locks.  Clients should never use the local protocol.
• Any CVS 1.10-supported platform can connect using pserver
  • Some platforms (such as Macintosh) don't like colons in CVSROOT
• Use forward slashes in the repository path for CVSROOT (or in the -d parameter) on [UNI]+X clients
• Does CVSNT on Linux support sspi???

Which protocol should I use?

CVS and WinCVS can access raw repository files via the local protocol which is extremely dangerous and will result in corrupt files and dangling file locks.  Only the non-local protocols use the Windows system service.  Clients should never use the local protocol.

pserver is by far the most compatible protocol.  It works with non-Windows NT/2000 clients such as Windows 95, Macintosh, and [UNI]+X.  pserver also works over the Internet although packets are unencrypted and passwords can be easily cracked.  pserver communicates over port 2401 -- consult your IT staff to open this port on your firewall.  CVSNT 1.10.8 doesn't let you enforce file permissions via pserver, but CVSNT 1.11 and later does.  If you don't use the pserver protocol, turn off pserver access because it represents a security risk.  Set the StartPServer registry setting to 0 (refer to the CVSNT readme) and restart the cvs service.

The sspi protocol is more secure than pserver but is less supported by CVS clients.

Another option is the kerberos protocol which is also less supported.  Refer to the CVSNT Readme for more information.

If you don't like the risks of pserver and sspi isn't an option for you, CVS also offers the SSH protocol (ext) in which all packets (including passwords) are encrypted via strong public key encryption.  It is possible to set up a SSH CVS server on Windows using CVSNT.  See SSH Access on Windows. 

Most people use the "Add" command in WinCVS.  Highlight a folder that's in the sandbox and click the + icon in the toolbar.  If that doesn't work for you, the new folder probably isn't in the right place.  The new folder must have a sibling CVS folder.

Try this from the command line:

c:\>mkdir sandbox
c:\>cd sandbox
c:\sandbox>cvs -d :sspi:tiger:c:/cvs checkout .

Note:  there above line ends with a space followed by a period.  Instead of a period you can specify a module name.  You can get a list of module names by entering:

cvs -d :sspi:tiger:c:/cvs co -c

c:\sandbox>mkdir newmodule
c:\sandbox>cvs add newmodule

Can clients connect over the Internet?

• The ext, pserver, sserver, kerberos, and sspi protocols work over the Internet
• pserver is the most widely supported protocol but it has security issues
• pserver and sspi require port 2401 to be open on client and server
• The relatively new sserver protocol runs over SSL and should be very secure (as of 2003/03/10, it is still unstable)
• SSH is the most widely supported secure protocol.  Here is a list of SSH products.  See also SSH Access on Windows.

Thanks to Are Bjølseth

1. pserver requires NT4 SP6 or later (e.g., Windows 2000)
2. Create an empty file .passwd (yes, with the dot in front of passwd) in the directory referenced by the HOME environment variable for the SYSTEM user (or the user that runs he CVS service)
3. Decide whether you want to use domain passwords or CVS passwords.  Using CVS passwords protects your domain passwords since pserver transmits passwords in an easily crackable format.
4. Update the config file in the CVSROOT module.  Change the line with #SystemAuth=no to SystemAuth=yes if you want to use domain passwords or SystemAuth=no if you want to CVS to authenticate using the passwords in the passwd file.
   • How to modify the config file:
     mkdir sandbox
cd sandbox
cvs -d :local:c:/cvs checkout CVSROOT
cd CVSROOT
edit the config file
     cvs -d :local:c:/cvs commit
5. If SystemAuth=no, create a passwd file in the CVSROOT directory
   • You must have access to the raw CVS repository files
   • The passwd file should never be checked into the CVSROOT module.  Just create the file passwd in the "raw" CVSROOT folder on the server.
   • The accepted formats of each line in the passwd file are as follows (consult the CVSNT readme):
     <username>:<encrypted-password>
<username>:!<domain>
<username>:<encrypted-password>:<real-username>
   • CVSNT 1.11.1.2 build 39 and later allow the domain to appear before the real-username, e.g., domain\username
   • If you don't specify the domain, use pwgen.exe to create  encrypted passwords i.e. username:ByupzkOsayjuk
     • Note that there is no domain name
6. If you have "impersonation" enabled for pserver, and SystemAuth=no, the users in the passwd file must map to real Windows users which must exist either on the local workstation, in a Windows domain, or in Active Directory. The Windows user name must appear in real-username.
7. On client machines use the CVSROOT
:pserver:username@tiger:c:/cvs
8. See below for troubleshooting
9. Clients should enter cvs login from the command line, or from WinCVS before attempting any CVS commands
10. WinCVS 1.2 configuration:
    Admin->Preferences
    General Tab
    "Enter the CVSROOT:"
    :pserver:username@tiger:c:/cvs
"Authentication": "passwd" on the cvs server
    "Use version": cvs 1.10 (Standard)
    From the Admin menu, select Login

Note that the account that the cvsnt service is running under needs 'Create a system level token' privilege to use pserver.

1. Each authorized user needs to have NTFS permissions to the CVS files on the server.  Read-write users need "full control."  Same applies to the temporary folder specified in the CVSNT control panel applet.  See more.
2. Clients don't need to enter cvs login from the command line, or from WinCVS, unless they log into a different domain
3. If users are in a different domain as the CVS server, be sure to put the user name (the domain name is optional) in the CVSROOT, e.g.,
   :sspi:username@servername:/test

If I use Windows domain security for password validation, how do I lock some users out?

1. Use NTFS (the hard way)
   •  
2. Use the passwd file (the easy way)

You must have access to the raw CVS repository files

Check out CVSROOT/config and set SystemAuth=no (see here)

Create a passwd file in the CVSROOT directory, on the CVS server.

The passwd file should never be checked into the CVSROOT module.  Just create the file passwd in the "raw" CVSROOT folder on the server.

Enter a line in the form of:
<username>:!<domain>

!<domain> is the domain that should be used to authenticate the user.

Absolutely!  dgloginfoemail sends notifications via email.  You just need to have CVSROOT/loginfo to execute this script instead.

See here

Generally it's easier to manage one repository rather than multiple repositories.  But your security needs may require you to have multiple repositories.  Your security needs will also dictate which protocol you use.  If different modules require different protocols, these modules should be managed by different repositories.

How can I control access to files?

For a particular module I want to give different users read, read-write, and "no" access.

See also How should I set up NTFS permissions on my repository?

Consult the cvs faq and the cvsnt readme for general authentication information. The readers and writers files allow you to control who has read and write access to the entire repository.  If you use sspi, I don't recommend you use this method of security.  Instead, control access using NTFS permissions because NTFS is more secure than CVS is.

The passwd file in the CVSROOT directory (Note: this file is not checked into CVS but is instead a raw file that must be edited directly) can be used to control who is allowed to access the respository for both the pserver and sspi protocols.  However, if you set SystemAuth=yes in the CVSROOT/config file (see here), the passwd file is essentially ignored.

If you want finer control beyond the entire repository...

Use NTFS file permissions for fine-grained access control to folders and files.  You can use the pserver, ext (ssh), or sspi protocols.

For pserver, if the "impersonate user" option for pserver is disabled, NTFS permissions only apply to the user that is running the CVSNT service.  Otherwise, the CVS user's NTFS permissions apply.

You must also set the LockDir option with CVSNT 1.x (no longer needed in CVSNT 2.x - see here.).  All users need "Full control" to the lock directory.  Do not put the lock folder inside a folder in the repository.  For example, if the repository is at c:/cvs, put the locks in c:/locks.  Note that the LockDir option option breaks the annotate feature in CVSWeb.

All users must also have "Full control" over the TEMP folder, which is set via the CVSNT control panel applet.

CVSNT has access control features which allow administrators to control fine-grained access to the repository without using NTFS permissions.  Consult the CVSNT Readme.  This can be useful, for example, if you use pserver without impersonation, or if you just don't want to deal with NTFS.  However, CVSNT-based security is less secure than NTFS.

CVSNT can enforce access control on a per-branch basis, which is something that NTFS can not do.  This is useful for stopping users from committing changes to particular branches.  

1. CVSNT runs on Linux and Windows platforms whereas the regular CVS server runs exclusively on [UNI]+X platforms.
2. Since CVSNT is a Windows application, it has a real install program, a service, and a control panel applet.
3. CVSNT supports UCS-2 and UTF8 Unicode files (UTF8 by default)
4. CVSNT allows branches to be "frozen" so only certain developers can commit files in them
5. Because CVSNT can run on Windows, most sample loginfo and notify scripts don't work because the scripts rely on a [UNI]+X shell environment.  See here for scripts that work on Windows.
6. CVSNT supports the -c option with the edit and commit commands and does not allow admin -l.  This is now standard CVS behavior.
7. CVSNT on Windows ignores filename case.  Foo.txt is the same as FOO.TXT.  This is very different from the way [UNI]+X-based CVS works.  This can make transitioning from [UNI]+X to Windows difficult (i.e., impossible) if there exists a folder in which two files only differ by case.  If you do this and you haven't driven yourself or your developers insane yet, stick with [UNI]+X.

Copying the raw repository files should work, which would preserve all tags and revisions.  However, it is not guaranteed to work -- the only 100% foolproof method is to use add or import.

Copying the raw repository files should work, which would preserve all tags and revisions.  However, it is not guaranteed to work -- the only 100% foolproof method is to use add or import.

Try vss2cvs or VSSExtractor

Just copy the raw repository files.  If any clients have the files checked out they will need to run this script.

1. Remove it via cvs remove
2. Log on the CVS server
3. Locate the file in the CVS repository
4. Remove the file from the Attic folder
5. Add the file using cvs add where the filename to add has the desired case

No.  Consider, for example, the command cvs edit.  Notifying users on the watch list is done on the server.  Otherwise you would have to configure all of the clients just right, and that's a nightmare.

See also read-only file attributes.

Clients should not access shared files on the CVS server directly.  Clients should use the non-local protocols.  The local protocol will lead to dangling file locks and possibly file corruption.

Clients should not store their sandboxes on remote shared folders.  WinCVS is known to use a lot of network bandwidth in this scenario.

CVS repositories can be stored on network shares.  The CVS server manipulates files in the shared folder.  This is often done for backup purposes.

The sspi protocol can not access network shares.

It can't.*  Don't try it.

OK, OK, it will work if you use the pserver protocol and turn impersonation off.  Make sure you run the CVSNT service under a user account that has access to the network share.

How do I re-add removed files?

Go to the folder where the file used to exist and run

cvs add filename

There is no way to do this from WinCVS.

This will recover the latest revision in the default branch.  If you want a different revision, the first thing you need to do is get the revision that you're interested in.  There are several ways to do this.

1. Check out a previous version of your project before your file was removed to another sandbox.  You need to specify a tag that was created on the file before it was removed.  Or you need to specify a timestamp before the file was removed.  Then copy the file over to your active sandbox.
2. CVSWEB allows you to view files in the attic.  WinCVS does not.  Copy the text from the browser and paste it in an editor.  Then save the file in your sandbox.

Once you have the file in your sandbox, "cvs add" it (click the add button in WinCvs).  When you commit the file will effectively be back on your development tree.

If you try to add a completely different file with the same name as a file that was previously part of your module but was removed, there will be some error messages complaining about the different file.  This happens because CVS tries to resurrect the attic file and load the diff into the RCS file and it finds the files are totally different.

A lot of CVS users don't think 1.11 is stable.  From my experience, 1.11 is stable.  The 1.11 tree has more features and bug fixes than the 1.10 version.  Of course, ongoing development means that some features may break inadvertently.

See also How can I control access to files?

Here's one way to do it.  Your needs may vary.

We have one group called CVSUsers which has every permission on almost every directory in the repository except "Full control."  Another group called CVSAdmins is for (surprise) CVS admins and has "Full control" to all files and directories in the repository.

CVSUsers has read-only access to all files in the CVSROOT directory, with the exception of the val-tags file which must be read/write.  CVSAdmins has "full control" over CVSROOT and its files.  Only CVSUsers and CVSAdmins have access to the repository, which helps keep the snoopers out.

CVSAdmins and CVSUsers have "Full control" to the LockDir directory (no longer necessary for CVSNT 2.x -- see here).

We don't want user to be able to create top-level folders on a whim (usually it's by accident).  Only the CVSAdmins group has write access to the root directory of the repository.  This stops CVSUsers from creating new modules.  There are some child directories under the root module directories that have the same protection.

Setting up permissions cvsweb is another thing, particularly if you want the browser to prompt for a user name and password. I discuss that at http://devguy.com/cvsweb

As far as I know, there are no formal studies to draw facts from, besides those that are either pro- [UNI]+X or pro-Windows, so anything you read about this topic is conjecture.

First, let's get this out of the way:  Windows is an excellent client for CVS, whether the server runs on Windows or [UNI]+X.  Nobody disputes that.

CVSNT is the best client to use on Windows compared to the "raw" CVS distribution or cygwin.

On the server side, the CVSNT server is very stable.  But, it may be less stable than its [UNI]+X cousins.  This is mostly due to bugs still lurking in CVSNT.  That is definitely up for debate, however, since CVSNT has a lot of bug fixes that aren't in the main CVS code.  Since the [UNI]+X and Windows products share a common code ancestry, most of the problems in CVSNT are caused by differences between the operating systems.

I am not aware of any CVSNT user that has a valid complaint about the operating system.  Windows NT is another matter and should be avoided at all costs.

The biggest problem about Windows vs [UNI]+X is the way in which Windows machines are typically abused.  Since Windows machines dominate the desktop market, Windows users tend to install and uninstall software, hard reboot, etc., more frequently compared to [UNI]+X users.  It should be obvious that a CVS server, whether Windows or [UNI]+X, should be locked down from casual usage.  Servers should not be used for word processing, game playing, or web surfing.  Remove the monitor and keyboard from your CVS server permanently.  Terminal Services makes it possible to do this.

CVSNT occasionally leaves behind "dead" CVS.EXE processes on the server.  A well-configured cron job can delete these processes late at night.  This is mentioned in the maintenance section.

There is an intermittent problem that affects some users more than others.  After committing a file, CVS still thinks the file has been changed.  After "updating" the file twice, CVS will agree that the file is up to date.

CVSNT sometimes returns the error "End of file (EOF)" when committing a file that needs to be merged (updated).  This can be very confusing for users.  [UNI]+X servers don't have this bug.  This bug might be fixed in the latest version of CVSNT.  Tony Hoyle, CVSNT's maintainer, is not able to reproduce it with regularity.

CVSNT's only secure protocol on the server are sspi and SSH.  The pserver protocol supports a more diverse list of platforms but pserver transmits the user's password using encryption that is easily cracked.  Instead, [UNI]+X servers can use SSH (:ext:) which is very secure.  While there are SSH servers for Windows, I have never used one with CVSNT, so I can't comment on whether SSH is a viable protocol on Windows.

There are, by far, more servers that run on [UNI]+X.  However, there are many experts on the CVSNT mailing list who resolve set-up problems and answer questions.

CVS and CVSNT Troubleshooting

• All of the files in WinCVS are marked red (meaning they have been changed) but I haven't changed any of them.

This is the infamous daylight savings time bug

• I can't get the CVS server to work with a shared folder

  See here

• Trouble using ntserver protocol with WinCVS 1.3

Upgrade to WinCVS 1.3 beta 8 or later.

• Bad repository root c:\cvs

You either didn't use ntservice -i c:\cvs or you didn't create the repository via cvs init

• cvs login: failed to open C:\/.cvspass for reading: No such file or
directory

Create an empty file .passwd (yes, with the dot in front of passwd) in the directory referenced by the HOME environment variable for the SYSTEM user (or the user that runs the CVS service)

• It is a very common mistake to check out code into the CVS root instead of the sandbox root.  Attempting to do this results in many error messages and weird behavior.  This will never happen if you follow the rule of thumb that the CVS server should not be used for any purpose.
  
• Another common mistake is to import a folder and then continue to modify files in the imported folder.  This is incorrect.  Instead you should create a new folder and check the module out into the new folder.  Then work on the checked-out copy.
• Set the password authentication first in the preferences !

This error is output by WinCVS when you select Admin/Login and you're not using the pserver protocol.  Logging in is only necessary when using the pserver protocol.

• I'm using Cygwin's SSH server and all commits are done by the user 'SYSTEM' instead of the actual user.

  This is an issue with Windows SSH implementations when public-key-only-authentication is used.  Password authentication doesn't have this problem.  Note that you can use public key and password authentication simultaneously.

• cvs [checkout aborted]: unrecognized auth response from caller: cvs

Make sure the user has NTFS permissions to the directory(ies) that is (are) being checked out.  Unless you have set the Lockdir option  (no longer necessary for CVSNT 2.x -- see here), the users must have "Full control."  Users must have "Full control" over the LockDir directory.  Also make sure the SYSTEM and remote users have "Full control" over the directory pointed to by the TEMP and TMP environment variables.

• After committing a file successfully, CVS (or WinCVS) still thinks the file needs to be committed

This is an intermittent bug in CVSNT's CVS.EXE when run on the client side.  To change the file's status, "update" it twice.  WinCVS has a handy short-cut for "update" which is control-U.

• Why are file timestamps off?

  I checked in a file at 10:00 AM but when I checked out the file, the file's timestamp was not 10:00 AM.

  CVS stores all times in UTC (universal coordinated time), which is the same as GMT (Greenwich Mean Time).  Generally, there shouldn't be any problems.  Windows displays the timestamp in your local time and CVS displays it in GMT. You might need to fix the GMT issue

• CVS server says something about not being able to find \WINNT\TEMP\1

  Check your TEMP and TMP environment variables.  They should be pointing to the same folder.  On the server they should be SYSTEM variables.  Make sure they are pointing to a valid folder.  Most importantly...

  Make sure that all of your CVS users have "Full control" to the temp folder and its sub-folders.  Ditto for the LockDir directory.
• I can't get non-Windows clients to work with the CVSNT server

1. Try using forward slashes instead of backslashes
2. Some platforms (e.g. Macintosh) don't like colons in CVSROOT -- try using UNC Names (with forward slashes instead of backslashes).
3. Another solution is to put the repository on the same drive as ntservice.exe  or cvsservice.exe.  Then CVSROOT specifies plain /cvs instead specifying the drive letter.
4. CVSNT 1.11 and later supports a new format:  instead of d:\projects\cvs, use /d//projects/cvs (note the double-slash)
5. CVSNT 1.11 has a "repository prefix" feature which is set via the control panel applet.  For example, you can set the prefix to c:\cvs and then use /cvs in CVSROOT which will be interpreted on the server as c:\cvs.

• I can't get the pserver protocol to work
  (Link as http://devguy.com/fp/cfgmgmt/cvs/cvs_admin_nt.htm#PSERVERPROB)
  
  (1)
  
  Make sure you followed the instructions (duh..)
  
  (2)
  
  Stop the CVSNT service and run cvsservice manually from the command line.

C:\>net stop cvs
C:\>cvsservice -test
CVS 1.11.1.1 (Build 24) (Jul 25 2001) starting in test mode.
Starting pserver on port 2401/tcp...
Bind to port failed... aborting - Error 997

(3)

From the command line on a client machine enter

telnet server_name 2401

It shouldn't disconnect immediately, it should sit there waiting for input.  If you press return it will then say BAD AUTH PROTOCOL.  If you can't connect there may be a firewall between the client and server, or some other program may be using port 2401 on the server. Try running TCPview to look for programs that are using port 2401 (which is very unlikely).  Then use TDIMon to see which program is using the port.  The obvious thing would be another instance of CVS running.

(4)

See also here

(5)

Use sspi if all of your clients are Windows NT, 2000, or XP.

(6)

Make sure 'require secure connection' on the CVS server has been turned off (Windows 2000 and possibly XP).  'Require secure connection' setting can be found via ControlPanel/ AdministrativeTools/ LocalSecurityPolicy ... select "IP Security Policies on Local Machine"

(7)

If you have Aventail Connect installed on the CVS server, perform the following:

1. Use Aventail Config Tool
2. Click "Advanced" tab
3. Click "Secure all servers except those listed
4. Press "Modify List" button
5. Press "Add" button, and locate cvsservice.exe
6. Click "All occurrences of 'cvsservice.exe'"
7. Press "Add" button, and locate cvs.exe
8. Click "All occurrences of 'cvs.exe'"
9. Click OK
10. File/ Save
11. Stop and restart Aventail

(8)

The account that the cvsnt service is running under needs 'Create a system level token' privilege to use pserver.

• Locking files results in an error

  (Link as http://devguy.com/fp/cfgmgmt/cvs/cvs_admin_nt.htm#locking)

  V:\>cvs admin -l
cvs [admin aborted]: 'admin -l' is a depreciated option. Use 'edit -c' instead.

  Or:

  cvs [admin aborted]: usage is restricted to repository administrators

  See also here

  First, you should reconsider locking files.  Only binary files and a small number of types of text files need to be locked in CVS.  CVS stands for CONCURRENT Versions System.  Multiple developers can modify the repository concurrently.  They can even (and often do) modify the same file at the same time.  More information is available on this topic at a high level.

  In general, when CVSNT complains that "only an administrator can run this command," it means that the user must be a CVS administrator.

  Anyway, CVSNT's replacement of admin -l is edit -c (click here).
• Commit / Edit results in errors like perl.exe unknown command
  • Make sure perl.exe is in your SYSTEM path
  • Make sure cvs_notify.pl , cvs_loginfo_email.pl , and cvs_loginfo_email.pl are in your SYSTEM path
  • Reboot if you change the SYSTEM path
    
• Commit / Edit results in 
warning: unrecognized response 'Can't call method "mail" on an undefined value at f:\perl\bin\cvs_notify.pl line 18.
  • This happens when the client is unable to talk to the SMTP server
  • Double-check the c:\perl\lib\cfgmgmt\globals.xml file and make sure the SMTP server is correct
  • See next
    
• "notify" / "commit" emails aren't received

More often than not, the problem is that the c:\perl\lib\cfgmgmt\globals.xml file doesn't have the correct SMTP server setting.  You can test this by running:

cvs_notify.pl youremail@yourdomain

and pressing control-Z, which is the end-of-file character for Windows (use control-D for [UNI]+X).  If the SMTP server can not be contacted you'll see the following error message:

Can't call method "mail" on an undefined value at cvs_notify.pl line 20.

• Users that have read-only NTFS permissions can't check out files

CVS is unable to create "lock" files in the repository on the server.  You need to set the LockDir option.   (no longer necessary for CVSNT 2.x -- see here)  E.g., if the repository is at c:/cvs, put the locks in c:/locks.

Note that using the LockDir option breaks CVSWeb's annotate feature.

• When the sandbox is on a shared folder, WinCVS "overloads" the remote file server with excessive i/o.

This is a known issue with WinCVS.  Sandboxes should be located on the local filesystem to avoid this problem.

• WinCVS locks up during/after a commit
  
  Go to the physical CVS repository and manually delete files that start with # or a comma
  
• end of file / EOF / recv() errors
  (Link as http://devguy.com/fp/cfgmgmt/cvs/cvs_admin_nt.htm#EOF)
   
  • If these messages appear while committing a file, it usually means the file needs to be updated
  • If not, make sure TEMP and TMP system environment variables are defined on the CVS server and they point to valid folders (they can point to the same folder)
  • Verify that all CVS users have "full" access to the temp folders on the CVS server
  • Verify that the user account that runs the CVS service has "full" access to the temp folders on the CVS server
  • Verify that the user account that runs the CVS service has read permission for CVSROOT/passwd and CVSROOT/config
  • Verify that the user has read permission for all files in the CVSROOT directory
  • Try running the cvs command with the -t switch
  • See also here
    
• cvs server: waiting for <userid>'s lock
cvs server: waiting for Unknown User's lock  Go to the folder where the raw repository files reside on the CVS server and manually delete files that start with # or a comma.

  This problem should be rare unless you're using the :local: protocol.  Don't use the local protocol.  This usually happens when the CVSNT server dies in the middle of execution, generally due to a bug in CVSNT.  It can also happen when the user doesn't have NTFS permissions to delete files in the repository folders on the server.  

• Fatal error, aborting.
Impersonation failed - configuration error.

(during checkout)

This happens when the SYSTEM user (or the user that's running the CVS service) doesn't have read permissions on the CVSROOT\passwd or CVSROOT\config files.  Check the permissions on any ancestor directories that CVSROOT is contained in.  Or, the user that runs the CVS service doesn't have the "Create a Token" privilege.

• unrecognized response (during commit)
  
  The file probably needs to be merged.  Use the cvs update command.
  
• cannot rename file foo to foo,v: Permission denied

  Make sure the user that is running the command has "full" control over the directory (and its child directories) specified in the LockDir option  (no longer necessary for CVSNT 2.x -- see here) and in the "temp" directory which is specified via the TEMP and TMP environment variables (on the client) and via the CVSNT control panel applet on the server.
• invalid argument (during commit)
  • If this message is output while committing a file, it usually means the file needs to be merged.  Use the cvs update command to updated the file.
  • If not, this usually happens when the CVS user doesn't have "Full control" over the folders referenced by the TEMP and TMP system environment variables defined on the CVS server, which is usually c:\winnt\temp
  • If this error message appears after setting the file permissions, it's likely that some temporary CVS files have gotten "stuck" due to an abnormal program termination.  The following steps will remedy the problem.
    1. Stop the CVS service by running
net stop cvs
    2. Run Explorer
    3. Navigate to to the CVS repository files
    4. Go to the folder that contains the file you are trying to check in
    5. Delete the file ,filename, where filename is the name of the file you are trying to check in
    6. Right-click on the file filename,v and select properties
    7. Check the read-only checkbox
    8. Click OK
    9. Navigate to c:\winnt\temp (or to whichever folder is pointed to by the TEMP environment variable) 
    10. Delete all folders that start with cvs-serv
        • If you use WinCVS 1.2 and see folders like these, it's very likely that there is at least one WinCVS 1.2 client that's using the wrong version of cvs2ntslib.dll -- refer to the CVSNT readme.  This does not apply to WinCVS 1.3 and later.
    11. Restart the service by running
        net start cvs

CVSWEBNT - CVSWeb for Apache and Microsoft IIS on Windows

See here

Installing ViewCVS on Windows for Microsoft IIS

See here