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.
Summary: | cvs co -- "checks out" and prepends an absolute path when it should be relative | ||
---|---|---|---|
Product: | obsolete | Reporter: | Jesse Glick <jglick> |
Component: | collabnet | Assignee: | support <support> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | rbalada |
Priority: | P1 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Shell transcript showing how to reproduce the problem |
Description
Jesse Glick
2001-01-29 19:17:12 UTC
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 |