I have run into a problem with client-server co where "-d ." is used in the module definition. A quick web search suggests that others have seen this problem in the last few months, but in no instance did I see a resolution to the problem. Say I have the following in my modules file: steve -d . devel/steve bob -d someplace devel/bob stuff -a steve bob If I do a simple "cvs co stuff" with CVSROOT=/home/steve/cvs (i.e. local), I have no problem. However, if I go to a remote machine and set CVS_RSH=ssh and set CVSROOT=:ext:steve@mymachine:/home/steve/cvs, cvs co stuff will only retreive bob. It will fail to get steve, returning an error: cvs server: existing repository /home/steve/cvs does not match /home/steve/cvs/devel/steve cvs server: ignoring module steve I've never moved the module. The bug has only arisen once the module was accessed in client-server mode (it continues to work fine locally, and the other modules continue to work fine in both local and client-server modes). I've tried it from two clients (linux 1.10.8 & solaris 1.10 `Halibut'), and with respect to two servers (linux 1.10.5 & solaris 1.10 `Halibut'), always with the same behavior. Any ideas as to what's going on? The system is used by a number of people locally, so I've not tried workarounds such as changing the "-d ." to something else (it might solve the problem, but it is not a viable solution for the existing users). Two things stand out for me: one is the use of -d ., the other is the coincidence that the path to the repository and the path for the module both happen to contain the substring "steve". --Steve _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs