The CVSNT FAQ

1. Installation issues
2. Server issues
   1. Pserver impersonation
   2. Error 'The :<whatever>: access method is not supported by this port of CVS
   3. Connection takes a long time (around 10 seconds)
   4. I get "Cannot open <path>/CVSROOT: Permission denied"
   5. I get "Cannot create directory <temp path>/cvs-servxxx: Permission denied"
   6. On a Win2003 server, Non administrator users cannot execute scripts
   7. What about upgrading from older versions of CVSNT?
   8. CVSNT crashed, but it couldn't write its crashdump file (error 5)
   9. CVSNT crashed and wrote a crashdump file
   10. I set up a new server, and it is much slower than my old server
3. Client issues
   1. On WinCVS I get 'remote server does not support the ls command' errors
   2. Location of TortoiseCVS.org FAQ
   3. Is Eclipse/WSAD supported by CVSNT?
   4. XP Home always logs in a 'Guest'
   5. Checking out to a remote samba share fails
   6. Error reading from server <whatever>: -1: Unknown error
   7. Can't authenticate - server and client cannot agree on an authentication scheme (got '')
4. HOW-TOs
   1. Which files changed between two tags/dates?
   2. Which files were committed with a commit, and what was committed?
   3. Can CVSNT require a check-in comment?
   4. How to set up the sserver protocol on (Debian) Linux
   5. How to merge a branch back to its ancestor
   6. How can I find out what protocols are supported by a CVSNT server?
   7. How to change a binary file to a text file (or vice versa)
5. Help! I'm still stuck

1. Installation issues

2. Server issues

2.1. Pserver impersonation

To successfully impersonate pserver on Win2000 and XP (pre-SP2) the server needs seTcbName ('Act as part of the operating system') enabled.

The default LocalSystem account has this privilege, so impersonation will work without problems. If you change the user that the service runs under you may have to explicitly grant this privilige to the user.

On Win2003 (also XP SP2?) the server will also need seImpersonationPrivilege enabled. This is also enabled by default on the LocalSystem account. If your administrator has removed this privilege then you may need to create a special user with it enabled.

2.2. Error 'The :<whatever>: access method is not supported by this port of CVS

If you see this you probably haven't installed the protocol when installing cvsnt. Note that :ntserver: protocol is no longer supported, and is replaced by :sspi:, which offers better functionality.

You should also make sure the cvs client executable provided with CVSNT is being used. Type 'cvs -v' on the command line to check this.

2.3. Connection takes a long time (around 10 seconds)

Normally the connection to the server should complete very quickly - less than a second in most cases. If you find that it is taking a long time there may be one of two problems:

• Misconfigured reverse DNS.

  • CVSNT does a reverse DNS lookup on startup to verify the client hostname. This will usually complete very quickly, however it is possible to misconfigure the reverse DNS in such a way that the lookup hangs and eventually times out after around 10 seconds. Your network administrator will usually be able to sort this out in a few minutes, as it's usually a simple misconfiguration. On NT4 machines there is a setting 'Use NetBIOS for DNS resolution' which may help. (Q: Is there an equivalent for W2K or do they always do it?)

• Very slow connection to PDC

  • CVSNT needs to contact the PDC to verify identities and check privileges. Normally across a LAN this will be quite quick, but over a saturated network or over a Dialup (in local mode) it can be very slow.

• See also http://support.microsoft.com/default.aspx?scid=kb;en-us;Q308512 for a possible solution.

• Another thing to try: Disable the virus checker on the machine that hosts the CVS server.

2.4. I get "Cannot open <path>/CVSROOT: Permission denied"

This error means that the LocalSystem does not have read access to your repository. The server needs to read the CVSROOT/ directory as LocalSystem before it switches to the identity of the logged in user.

Note that LocalSystem is not a member of the 'Everyone' group and has to be given specific priviliges.

(If you are running the server under a different user to the default then replace 'LocalSystem' with the user that you are using).

See also SetACLS aka How I Set Up CVSNT Permissions

2.5. I get "Cannot create directory <temp path>/cvs-servxxx: Permission denied"

This error means that your temporary directory does not have write acess for the user you are logged in as. On XP and Win2003 this can be a problem because the default global temporary directory is read only for normal users. The solution is to use a special CVS temporary directory and tell CVSNT to use it via the control panel (see the various installation guides for details on that). The temporary directory needs write access for everyone that will be using CVS remotely. (Q? Shouldn't have to give LocalSystem access here - need to check).

See also SetACLS aka How I Set Up CVSNT Permissions

2.6. On a Win2003 server, Non administrator users cannot execute scripts

By default on Win2003 only Administrators can execute scripts. This causes failure of the loginfo/commitinfo scripts on the server. To remedy this make sure that ordinary users have execute permissions to cmd.exe, and read/execute to the script you are executing.

2.7. What about upgrading from older versions of CVSNT?

This is straightforward. See the Upgrading page for more information.

2.8. CVSNT crashed, but it couldn't write its crashdump file (error 5)

Check the permissions on the temporary directory that CVSNT is trying to write to, and make sure that the permissions are such that both the user you are using and LocalSystem can write to it (note: LocalSystem is not a member of 'Everyone'). Sometimes this isn't enough - the reason for this is unknown but it appears to be an OS bug.

2.9. CVSNT crashed and wrote a crashdump file

Firstly, please try to repeat this on the latest revision if you haven't already - the older a version is that caused a crash, the less useful it is to the developers.

When you manage to get a crashdump, zip it up and send it to cvsnt-crashdumps@cvsnt.org, along with an explanation of how you created the crash.

2.10. I set up a new server, and it is much slower than my old server

Arthur Barrett wrote about slow checkouts (but that can be adapted to other scenarios):

There are so many variables in a CVSNT installation what you need to do is start isolating things.

Firstly isolate the network.

Do the same checkout on the server using :local: protocol then also on the server using :pserver: protocol. If this is slow then the problem is on the server someplace. Try moving the repository to a USB stick or a RAM disk and re-test to isolate the disks.

If the speed is fine on the server then you need to start looking at different clients. Again there was a thread some time ago where one switch or network card (can't remember which) was causing the problem.

Finally if you trace (cvs -ttt co module) then each action has a timestamp - it may be possible to "see" some specific points in the trace which are taking too long to execute.

3. Client issues

3.1. On WinCVS I get 'remote server does not support the ls command' errors

The server-side ls command is only supported on CVSNT servers. There are two solutions - either uncheck 'List' in the select module dialog (WinCVS will then use the co -c command, which lists the CVSROOT/modules file on the remote server), or upgrade the server to a CVSNT server.

3.2. Location of TortoiseCVS.org FAQ

TortoiseCVS maintains a separate FAQ at: http://www.tortoisecvs.org/faq.html

3.3. Is Eclipse/WSAD supported by CVSNT?

If Eclipse detects a CVSNT server it will refuse to connect. This is a decision by the Eclipse developers and not under the control of CVSNT.

CVSNT servers since 2.0.35 have a flag which pretends to be a standard Unix server, so that Eclipse lets you in (you *must* use a repository prefix for this to work - Eclipse doesn't support drive letters). This method of operation is not supported officially by either the CVSNT or Eclipse developers.

Since Eclipse 3.0 M9 and upwards, repository paths must match exactly the case of the repository paths set in the CVSNT control panel. If it is not done this way eclipse will see the repository and the files, but won't see the branches or versions.

If you have a problem with the interoperability try to get a client/server trace from eclipse before reporting bugs as it's difficult for the developers without diagnose problems without this detail.

3.4. XP Home always logs in a 'Guest'

Using SSPI XP Home will always log in as 'Guest' by default. XP Pro will also do this if 'Simple File Sharing' is enabled.

On XP Home the only workaround is to explicitly specify the username in the CVSROOT string, which will override the default. On XP Pro it is strongly recommended to disable 'Simple File Sharing' (commonly known as 'Broken File Sharing').

3.5. Checking out to a remote samba share fails

Storing sandboxes on remote shares is not supported. Use a Unix client on the remote machine to checkout the sandbox, or use a local drive on the NT machine.

3.6. Error reading from server <whatever>: -1: Unknown error

This means that the client was able to connect to the server, but something disconnected it before authentication could take place.

The usual cause for this is Antivirus and/or 'Personal' firewalls, which can break Handle Inheritance. To verify the culprit uninstall all such programs from your machine and try again (simply disabling them is usually not enough). If it then works re-install the software until you find which one is causing the breakage (then file a bug with the vendor concerned).

If all else fails try WinsockXPFix which restores the TCP/IP stack to a working state after spyware/AV/firewalls cause problems.

In particular the Nod32 av exhibits this behaviour. The current workaround is to disable the 'IMON' service and reboot. Eset have been contacted about this problem. Until it is fixed it is recommended that Nod32 is not used on a machine running cvsnt.

Also known to break the stack is Aventail AutoSocks. No known workaround other than to uninstall it.

3.7. Can't authenticate - server and client cannot agree on an authentication scheme (got '')

This is the same as the -1 error above.

4. HOW-TOs

4.1. Which files changed between two tags/dates?

Use the 'cvs rdiff' command with the -s option, like this:

• cvs rdiff -s -r tag1 -r tag2 module 2>0

• -s reduces the output to one summary line per file (changed/added/removed)

• -r indicates the tag(s) to use for the diff. Use only one -r option if you want to diff against the HEAD.

• module is a proper module path on your server. (This command is by default recursive, like almost all cvs commands.)

• 2>0 hides the informational output which module is being diffed (shows also modules that don't contain any differences). Remove this if you want to see this information.

4.2. Which files were committed with a commit, and what was committed?

First use the 'cvs log' command to get the commit id. It is part of the output ('commitid:').

Then use 'cvs -q log -SR -r@{commitid}' (replacing {commitid} with the number from the log output) to retrieve a list of files that were committed together with that commit.

You can also use 'cvs diff -r@<{commitid} -r@{commitid}' (again replacing {commitid} as above) to retrieve a diff for all files in that commit against the previous revision.

4.3. Can CVSNT require a check-in comment?

Basically this can be done in a server-side script (see the commit support file verifymsg). However, the consensus among most repo admins seems to be that it's better to educate the users than to require a commit comment through coding, as the latter can easily be circumvented by typing phony comments.

An example script can be found in ForceCommitComment.

4.4. How to set up the sserver protocol on (Debian) Linux

Chris Purves wrote the following in the cvsnt support group on 2007-07-05:

Alright, to get sserver to work I did the following:

1. Download source (for Debian from /usr/src/, #apt-get source cvsnt)

2. Find genkey script (for Debian, located in /usr/src/cvsnt-2.5.03.2382/contrib)

3. Run genkey (creates cert and key: aimsnet.crt and aimsnet.key in my case)

4. Move created cert and key to /etc/cvsnt

5. Update /etc/cvsnt/PServer with the following two lines:

   • CertificateFile=/etc/cvsnt/aimsnet.crt
     PrivateKeyFile=/etc/cvsnt/aimsnet.key

4.5. How to merge a branch back to its ancestor

Often developers create a temporary branch for a feature development. They usually merge changes to the stable branch (or something like it) regularly into their temporary branch, and at the end they want to put their branch back into the stable branch. The best way to do that is to run a final merge from the stable branch (let's call it "bStable") to the temporary branch ("bTemp"), and then use the following sequence to put the temporary branch bTemp back to the stable branch bStable:

(Taken from Tony Hoyle's message http://www.cvsnt.org/pipermail/cvsnt/2006-June/025292.html.)

See also the full discussion in http://tinyurl.com/2t6v6c.

4.6. How can I find out what protocols are supported by a CVSNT server?

Use a form of 'cvs info' (requires both a CVSNT client and server) http://www.cvsnt.org/manual/html/info.html.

• 'cvs info' shows you the protocols installed with the local CVSNT installation; that is, the ones that are available for use as a client.

• 'cvs info -s' shows you the protocols that are enabled for communication with the local CVSNT installation as server. (This one seems to hang if the server process is not running; for example with client-only installations.)

• Use 'cvs info -r <server>' for checking the protocols available (and some additional info) on a remote server.

4.7. How to change a binary file to a text file (or vice versa)

The following instructions change the -k options of a file to -kkv, but they can be used to change the -k options in any way.

Note: check the contents of file.ext and if they are incorrect then replace with some/place/safe/file.ext and commit.

(Contributed by Arthur Barrett to the support.cvsnt newsgroup on 2007-12-12.)

5. Help! I'm still stuck

March-Hare Software Ltd do a complete service contract with includes installation and after-sales support. See http://www.cvsnt.com.