Bug 9283 - cvs co -- "checks out" and prepends an absolute path when it should be relative
cvs co -- "checks out" and prepends an absolute path when it should be relative
Status: RESOLVED INVALID
Product: obsolete
Classification: Unclassified
Component: collabnet
3.x
PC Linux
: P1 (vote)
: TBD
Assigned To: support
issues@www
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-29 19:17 UTC by Jesse Glick
Modified: 2009-11-08 02:27 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Shell transcript showing how to reproduce the problem (9.90 KB, text/plain)
2001-03-13 15:18 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2001-01-29 19:17:12 UTC
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.
Comment 1 Unknown 2001-03-03 02:44:33 UTC
need more information about this bug and how to reproduce it.
Comment 2 support 2001-03-05 23:37:05 UTC
accepting for investigation
Comment 3 Jesse Glick 2001-03-10 13:07:00 UTC
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).
Comment 4 rbalada 2001-03-12 18:47:29 UTC
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$
<!-- -->
Comment 5 Jesse Glick 2001-03-12 18:56:38 UTC
Note that in my experience this bug only occurs when checking out a branch,
never the trunk.
Comment 6 kat 2001-03-13 05:40:42 UTC
Jesse,

what options are you using for the checkout?
 
Comment 7 Jesse Glick 2001-03-13 15:17:24 UTC
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.
Comment 8 Jesse Glick 2001-03-13 15:18:28 UTC
Created attachment 769 [details]
Shell transcript showing how to reproduce the problem
Comment 9 kat 2001-03-13 23:14:43 UTC
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
Comment 10 kat 2001-03-14 22:29:10 UTC
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
Comment 11 Jesse Glick 2001-03-15 14:34:41 UTC
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.
Comment 12 kat 2001-03-15 18:57:44 UTC
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
Comment 13 support 2001-03-15 21:24:13 UTC
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.
 
Comment 14 Jesse Glick 2001-03-16 15:24:13 UTC
OK, sounds good--thanks for investigating.
Comment 15 Taska 2001-10-05 01:26:02 UTC
reopening in order to re-close resolved fixed.
Comment 16 Taska 2001-10-05 01:26:21 UTC
re-closing resolved fixed.
Comment 17 Unknown 2004-10-13 09:05:56 UTC
closing...
Comment 18 Marian Mirilovic 2009-11-08 02:27:13 UTC
We recently moved out from Collabnet's infrastructure


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo