I think this may be duplicate, but in any case it happened to me recently (Jan
I tried to check out the branch splitloaders_jan2001 from CVS. All of my
CVS/Repository files had the string:
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
need more information about this bug and how to reproduce it.
accepting for investigation
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
I have the same problem, but on Solaris 8.
I want to especially note, that I used -f switch in checkout.
builder@ultra60-1:/space/NetBeans/night_build/release32/repo$ cvs -d
:pserver:email@example.com:/cvs update -rrelease32-BLD0 -f -d -P ant
apisupport applet autoupdate beans clazz debuggercore debuggerjpda debuggertools
editor extbrowser form html httpserver i18n icebrowser image jarpackager java
javacvs javadoc jndi objectbrowser openidex projects properties scripting rmi
text usersguide utilities vcscore vcscvs vcsgeneric web
protocol error: directory
'/usr/local/tigris/data/helm/cvs/repository/ant/javahelp' not within root '/cvs'
Note that in my experience this bug only occurs when checking out a branch,
never the trunk.
what options are you using for the checkout?
OK, I figured out how to reproduce this! It is obscure. It only happens the
*first time* you check out a given branch! I will attach a shell transcript.
Created attachment 769 [details]
Shell transcript showing how to reproduce the problem
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.
This issue is adressed in our new versioning tool, Subversion
At this time though it is a feature of CVS, which is still being used in
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
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.
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.
OK, sounds good--thanks for investigating.
reopening in order to re-close resolved fixed.
re-closing resolved fixed.
We recently moved out from Collabnet's infrastructure