Misleading CVS behavior

[Rick Genter]

Using the following versions:

C:\Documents and Settings\rgenter\My Documents\test>cvs version
Client: Concurrent Versions System (CVSNT) 2.0.41a (client/server)
Server: Concurrent Versions System (CVS) 1.11.17 (client/server)

C:\Documents and Settings\rgenter\My Documents\test>

If I try to check out a non-existent branch of a module using WinCVS, I
get the following output:

C:\Documents and Settings\rgenter\My Documents\test>cvs co -r
r3_0_1_integration Sentinel
cvs checkout: Updating Sentinel
cvs checkout: Updating Sentinel/classes
cvs checkout: in directory .:
cvs checkout: cannot open CVS/Entries for reading: No such file or
directory

C:\Documents and Settings\rgenter\My Documents\test>

Note that I don't get the line "tag does not exist". That's because the
tag does exist in the repository, just not for this particular module.
The result? Very confused developers who don't understand why they
couldn't check out the module...

I'm not sure which end is to blame - the client or the server - thus I'm
posting this to both mailing lists.

(FYI, the reason we are not running CVSNT on the server is that I was
unable to get 2.0.41a to build on OpenBSD 3.3, which is our CVS server.
Someday I'll move the server to Linux, but I don't have the time right
now to do that, so I'm stuck with cvshome.org CVS for now, which did
build on OpenBSD 3.3.)

The CVSNT client installation came with WinCVS 1.3 Beta 17 Build 2
(which is how we originally found this problem, where it is even more
confusing, because after the "cannot open CVS/Entries for reading..."
line, WinCVS reports that CVS exited with return code 0, indicating
success). I'd prefer not to have to go to a version that is not
officially "stable" if at all possible. I just wanted to make sure this
bug was known; I'll keep my eye to the screen for a future "stable"
release that fixes it. Thanks.

--
Rick Genter
Sr. Software Engineer
Silverlink Communications
<mailto:rgenter@silverlink.com>
(781) 272-3080 x242