GNU Info

(cvsbook.info)General Troubleshooting Tips

---

Next: Some Real Life Problems (With Solutions) Prev: The Usual Suspects Up: Tips And Troubleshooting

---

Enter node , (file) or (file)node

General Troubleshooting Tips
============================

The bulk of this chapter is organized into a series of questions and
answers, similar to an Internet FAQ (Frequently Asked Questions)
document.  These are all based on actual CVS experiences.  But before we
look at individual cases, let's take a moment to consider CVS
troubleshooting from a more general point of view.

The first step in solving a CVS problem is usually to determine whether
it's a working copy or repository problem.  The best technique for doing
that, not surprisingly, is to see if the problem occurs in working
copies other than the one where it was first noticed.  If it does, it's
likely a repository issue; otherwise, it's probably just a local issue.

Working copy problems tend to be encountered more frequently, not
because working copies are somehow less reliable than repositories, but
because each repository usually has many working copies.  Although most
working copy knots can be untied with enough patience, you may
occasionally find it more time-efficient simply to delete the working
copy and check it out again.

Of course, if checking out again takes too long, or there is
considerable uncommitted state in the working copy that you don't want
to lose, or if you just want to know what's wrong, it's worth digging
around to find the cause of the problem.  When you start digging around,
one of the first places to look is in the CVS/ subdirectories.  Check
the file contents and the file permissions.  Very occasionally, the
permissions can mysteriously become read-only or even unreadable.  (I
suspect this is caused by users accidentally mistyping Unix commands
rather than any mistake on CVS's part.)

Repository problems are almost always caused by incorrect file and
directory permissions.  If you suspect a problem may be due to bad
repository permissions, first find out the effective repository user ID
of the person who's having the trouble.  For all local and most remote
users, this is either their regular username or the username they
specified when they checked out their working copy.  If they're using
the pserver method with user-aliasing (see the section Note: Anonymous
Access in Note: Repository Administration), the effective user ID is
the one on the right in the CVSROOT/passwd file.  Failure to discover
this early on can cause you to waste a lot of time debugging the wrong
thing.

And now, without further ado...