I think this may be duplicate, but in any case it happened to me recently (Jan
2).
I tried to check out the branch splitloaders_jan2001 from CVS. All of my
CVS/Repository files had the string:
/usr/local/tigris/data/helm/cvs/repository/
prepended to them for some reason. (Normally the Repository should not be an
absolute path, rather be relative to the base directory of the repository.) Any
operations on such a working dir give:
protocol error: <<something>> not within root /cvs
Strip off this prefix, and all is OK. I think the problem lies in your symlink
from /cvs to the above canonical path. Someone said that there was a bug in your
CVS binary but I thought it had been fixed long ago. Maybe there was a
regression here.

This is reproducible (for me) and a real problem. I just tried to check out our
new release32_base branch (well actually the base revision for it) and while
that worked, I get the mentioned protocol error trying to e.g. cvs log files
from inside it.
I am using CVS 1.10.6 (via RPM, cvs-1.10.6-2) on RedHat Linux 6.1 (kernel
2.2.12). Accessing the server via SOCKS5 proxy (basically same as direct
access).

Hi,
Thank you for the output, it helped to clarify what is going on.
Basically, an entry in /cvs/CVSROOT/val-tags for the branch is not being created
until after the first checkout, which is why the absolute rather than relative
path is being prepended.
I am doing some testing now to see if this is related specifically to the
version of CVS being used on the site and investigating options.
Thanks,
Kat

This issue is adressed in our new versioning tool, Subversion
(http://subversion.tigris.org/index.html).
At this time though it is a feature of CVS, which is still being used in
SourceCast 1.0.
Thank you,
Kat

It is not a "feature" of CVS, it is a bug in your installation of CVS (caused
perhaps by your use of a symlink for the repository root) which does not appear
in other installations.
When is subversion slated to be included in SourceCast? I was under the
impression it was still in an early stage of development. According to its home
page it does not even support remote operation yet. Assuming normal SW
development cycles, that means at least a year and probably more before it will
be usable in production environments. In the meantime will no CVS-related bugs
be touched?
This one is perhaps not so important because there is a simple workaround (once
you know it), but surely things which interfere with the development cycle
cannot be dismissed this way.

I realize that cvs issues are important, and will continue to be adressed.
Prior to responding last time I spoke with a developer who works on the cvs
portion of SourceCast. You are correct that the behavior is due the the simlink
to repository root, but he informed me this behavior would be present in 1.0
release of SourceCast because it was the most workable in the current system and
pointed toward Subversion as a solution to this due to the handing of branches
as clones of the tree.
I also formally submitted this as an issue and will keep you updated.
Kat

My misunderstanding on this issue. This behavior is not present on SourceCast
1.0. Cvs will store both a client and server view of the repository this will
mean that the client will always get a consistent message back about the
location of the repository.
I appologize for the runaround and confusion on this issue.