GNU Info

Info Node: (cvsbook.info)Some commands fail remotely but not locally; how should I debug?

(cvsbook.info)Some commands fail remotely but not locally; how should I debug?


Next: I do not see my problem covered in this chapter Prev: How can I get a list of all projects in a repository? Up: Some Real Life Problems (With Solutions)
Enter node , (file) or (file)node

Some commands fail remotely but not locally; how should I debug?
----------------------------------------------------------------

Sometimes there's a problem in the communication between the client and
the server.  If so, it's a bug in CVS, but how would you go about
tracking down such a thing?

CVS gives you a way to watch the protocol between the client and server.
Before you run the command on the local (working copy) machine, set the
environment variable `CVS_CLIENT_LOG'.  Here's how in Bourne shell
syntax:

     floss$ CVS_CLIENT_LOG=clog; export CVS_CLIENT_LOG

Once that variable is set, CVS will record all communications between
client and server in two files whose names are based on the variable's
value:

     floss$ ls
     CVS/        README.txt    a-subdir/    b-subdir/    foo.gif     hello.c
     floss$ cvs update
     ? clog.in
     ? clog.out
     cvs server: Updating .
     cvs server: Updating a-subdir
     cvs server: Updating a-subdir/subsubdir
     cvs server: Updating b-subdir
     floss$ ls
     CVS/              a-subdir/    clog.in     foo.gif
     README.txt        b-subdir/    clog.out    hello.c
     floss$

The `clog.in' file contains everything that the client sent into the
server, and `clog.out' contains everything the server sent back out to
the client.  Here are the contents of clog.out, to give you a sense of
what the protocol looks like:

     Valid-requests Root Valid-responses valid-requests Repository           \
     Directory Max-dotdot Static-directory Sticky Checkin-prog Update-prog   \
     Entry Kopt Checkin-time Modified Is-modified UseUnchanged Unchanged     \
     Notify Questionable Case Argument Argumentx Global_option Gzip-stream   \
     wrapper-sendme-rcsOptions Set expand-modules ci co update diff log add  \
     remove update-patches gzip-file-contents status rdiff tag rtag import   \
     admin export history release watch-on watch-off watch-add watch-remove  \
     watchers editors init annotate noop
     ok
     M ? clog.in
     M ? clog.out
     E cvs server: Updating .
     E cvs server: Updating a-subdir
     E cvs server: Updating a-subdir/subsubdir
     E cvs server: Updating b-subdir
     ok

The clog.in file is even more complex, because it has to send revision
numbers and other per-file information to the server.

There isn't space here to document the client/server protocol, but you
can read the `cvsclient' Info pages that were distributed with CVS for
a complete description.  You may be able to figure out a good deal of
it just from reading the raw protocol itself.  Although you probably
won't find yourself using client logging until you've eliminated all of
the other possible causes of a problem, it is an invaluable tool for
finding out what's really going on between the client and server.


automatically generated by info2www version 1.2.2.9