This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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.
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 access).
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:rbalada@cvs.netbeans.org:/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' builder@ultra60-1:/space/NetBeans/night_build/release32/repo$ <!-- -->
Note that in my experience this bug only occurs when checking out a branch, never the trunk.
Jesse, 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
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.
OK, sounds good--thanks for investigating.
reopening in order to re-close resolved fixed.
re-closing resolved fixed.
closing...
We recently moved out from Collabnet's infrastructure