-d . bug

[Steve Blackburn]

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