|
|
If you are having difficulty connecting to a repository, first check that the repository path is declared correctly. The most common mistake when checking out a new sandbox is to forget to specify the repository path at all. Another common mistake is to forget to specify the connection method if you are using a method other than local or ext.
If you want to examine the data sent to or received from the server, set the CVS_CLIENT_LOG environment variable to a file name. It must be set on the client computer, and the traffic is logged in files in the current working directory named for that filename, with the suffixes .in and .out. For instance, if you set CVS_CLIENT_LOG to cvslog, the traffic is logged to cvslog.in and cvslog.out. (Traffic to the server is logged to cvslog.in, and traffic from the server is logged to cvslog.out.)
The gserver, kserver, and pserver connection methods rely on a server that is started with inetd. inetd sets a limit on the number of connections per unit of time and delays further connections. If you expect heavy use of CVS, you may need to configure inetd to accept more connections per minute. Not doing so may cause connection refused error messages.
If you are in an active sandbox and are receiving an error like the one shown in Example 9-2, the Root or Repository file in the CVS subdirectory of the current sandbox directory has become unreadable. Chapter 6 includes an explanation of these files and what they should contain, but the simplest way to correct a problem in a sandbox is to remove and recreate the sandbox. If there are changes in the sandbox files, be sure to preserve them before removing the sandbox.
cvs update: No CVSROOT specified! Please use the `-d' option cvs [update aborted]: or set the CVSROOT environment variable.
Certain changes in a repository or a repository's host environment can cause the Root and Repository files in a sandbox to be out of date. Examples of these changes include a change to the repository computer's hostname, a change to the user's username, and a change in the preferred connection method. The traditional way to manage these changes is to commit and release the sandbox beforehand and create a new sandbox afterward.
If you do not want to create a new sandbox, you can edit the appropriate files in the sandbox. Example 9-3 is a small script that relies on bash and perl to change the hostname in a sandbox Root file automatically.
find ~/cvs/wizzard -name Root | xargs perl -p -i'.bak' -e "s/helit/lat/;"
Some of the access methods require configuration. The pserver, kserver, and gserver methods require configuration at the repository, and the ext, kserver, and gserver methods require configuration at the sandbox. Example 9-4 shows the error that occurs when the pserver method is used but the user does not exist in the repository's user database. Example 9-5 shows the error that occurs when kserver is used but the client is not compiled to support it.
bash-2.05a$ cvs -d :pserver:cvs:/var/lib/cvs checkout wizzard no such user jenn in CVSROOT/passwd
bash-2.05a$ cvs -d :kserver:cvs:/var/lib/cvs checkout wizzard cvs checkout: CVSROOT is set for a kerberos access method but your cvs checkout: CVS executable doesn't support it. cvs [checkout aborted]: Bad CVSROOT: `:kserver:cvs:/var/lib/cvs'.
In addition to checking the configuration of the access method, check that the username you're trying to use exists on the server and has access to the repository project files you are trying to reach.
If you are using the pserver access method, also check that the passwd file in the repository's CVSROOT directory is mapping your CVS username onto an existing system username with the appropriate permission. If you are using Kerberos 4 or the GSS-API with Kerberos 5, ensure that you have a Kerberos username and a current ticket and ensure that the CVS server has its ticket.
Isolating a problem is a common and useful troubleshooting tactic. If you are having trouble accessing a repository, there may be a problem with the protocol you are using to connect with, the configuration of either CVS or the protocol, or, more rarely, the CVS code. To fix your problem, you need to figure out where it is.
There is a common set of client and server code used by all CVS remote-access methods. The fork connection method can be used to determine that this common CVS code is functioning correctly. To determine whether Kerberos, the GSS-API, rsh, or your rsh replacement are working, you can use a simple service with the same protocol as the method you are having trouble with.
To test whether a connection problem is caused in CVS itself, try using the fork access method to create a sandbox on the same computer as the repository. If this fails, check your repository path and check that the project name you are using is valid. If both are correct, there is a problem in the CVS client and server code that should probably be reported as a bug. Example 9-6 shows what should happen when you test the server with fork.
jenn@helit:/tmp$ cvs -d :fork:/var/lib/cvs checkout wizzard cvs server: Updating wizzard U wizzard/Changelog U wizzard/INSTALL U wizzard/Makefile U wizzard/README U wizzard/TODO cvs server: Updating wizzard/doc cvs server: Updating wizzard/doc/design . . .
If the fork test shows that your repository path and project name are valid and that the common CVS server is functioning correctly, you can isolate the problem further by testing the access method with a simple program that uses the same protocol. You must do this with the protocol client you are attempting to use with CVS, and you must use the same hostname. Kerberos 4 or 5 can be tested with the Kerberos rsh replacements, and ext or server can be tested with rsh. If ext is used with a replacement for rsh, that replacement should be used in the test. You can test pserver with telnet.
Example 9-7 shows a successful attempt to connect to a host named cvs using the SSH protocol. SSH clients are commonly used as rsh replacements.
bash-2.05a$ ssh cvs Linux helit 2.4.19-686-smp #1 SMP Thu Aug 8 22:06:13 EST 2002 i686 unknown unknown GNU/ Linux . . . Last login: Mon Nov 11 04:24:55 2002 from 10.0.2.2 jenn@helit:~$
If you are using the ext connection method, you can choose from many programs to manage your connection; however, such a choice can cause problems.
The replacement must not convert line endings, as CVS expects to do that itself. If your replacement converts line endings, CVS is unable to determine where the end of each line is, so the merge methodology fails.
The replacement must accept the following syntax:
program [-b] [-l username] host commands
The -b is optional if you are not using OS/2, but the rest of the syntax is required.
The repository server must be running a server process that can accept the protocol the replacement is using and that can run the commands sent by the rsh-replacement program. To test most of these requirements, you can run a command that uses the full syntax, as shown in Example 9-8.
bash-2.05a$ ssh -l jenn cvs ls /tmp iio makemain wizzard
If you need to pass a command or call an option to your rsh replacement, you can do so by creating a small script and calling that script instead of the replacement program. Example 9-9 shows one such script.
#!/bin/bash exec ssh -i /home/jenn/.RSAkey "$@"
|
|
|
| Top |