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.
We found that we are not able to rtag sources. Latest succesful rtagging was done on 2001-09-24 03:10 UTC (2001-09-23 20:10 PDT). Next rtag was tried on 2001-09-25 03:25 UTC (2001-09-24 20:25 PDT) and was not successful. Attaching assertion log. 2 steps to reproduce: $ cvs co nbbuild/tagref $ cvs rtag my_extraordinary_tag nbbuild/tagref This bug was discussed with Michael Boyer, before reassigning read attached assertion log.
Created attachment 2801 [details] Assertion log from rtagging
Assigning to support
Accepting issue for CollabNet support, pcn 5875.
Accepting.
The workaround is to use "tag" instead of "rtag". In order to use tag, you have to be in the same directory as the thing you want to tag. Here's the commands that worked for me on the staging server: > mkdir netbeanstest > cd netbeanstest > cvs -d :pserver:you@cvs.netbeans.org:/cvs login > cvs -d :pserver:you@cvs.netbeans.org:/cvs co nbbuild/tagref > cd nbbuild > cvs tag yourtag tagref To view the change, do a log of the file: > cvs log tagref Check for the tag at the very top of the taglist. It should look approx. like this: yourtag: 1.2 If you have any concerns or questions, please include your phone number here and we can have our developer give you a call.
Rudolf and RE, please determine if this workaround is acceptable to get the short term goal of getting the Q-Build built. Also comment if it's an acceptable solution long-term?
As a short term solution it's acceptable. It was recommeded to developers on nbdev. For long term solution we need to get it fixed. It should not take over one month, because the most of scripts must be checked and updated to use tag instead of rtag and a few manual processes must be reviewed to fit current tagging possibilities. It need to be fixed also for better tagging options connected with rtag command.
More Info: Based on the last successful rtag, 9/23 20:10 PDT and the unsuccessful one, 9/24 20:25 PDT, and the CVS upgrade, which was marked as complete 9/23 22:50, it looks like the last set of CVS upgrades caused the problem The reason this wasn't reported on 9/24 20:25 PDT was because the scripts didn't report on this error. It wasn't until people looked for the tags of the Q-Build and couldn't find them, that the log research was done and the rtag error was identified. We need to identify which CVS patch that caused the problem and investigate if we need to backout the fix until this problem is resolved.
There was only one CVS package installed/upgraded on 9/23, and we have determined that this is indeed causing the problem; specifically, the path-name fixes in CVS resulted in this problem. I have spoken to the developer, who says the core issue is an installation convention which results in the /cvs directory being a sim-link instead of a real directory. We have launched an internal review to determine how we can solve both the path-name issues and the rtag issue at the same time, possibly by changing our installation convention. I am moving this to a P2 and will continue updating with our progress. Please inform us as to your urgency level; the one thing that we may be able to do quickly is to remove the most recent upgrade, which would cause the other CVS errors to return.
This is an urgent issue, although since we do now have a workaround, (although a painful one), we'll leave it as a P2. It should be considered the top P2. We are in the process of determining which is worse for us. Living (for a short term) with the workaround or backing out and having the other CVS bugs. Please give us an idea of the scope of this problem and an idea of resolution date.
I now tried to execute following command: cvs -d :pserver:jlahoda@cvs.netbeans.org:/cvs checkout -r cpplite_dev6 cpplite and similiar error (attached for reference) was thrown. The sources were tagged via above workaround.
Created attachment 2838 [details] Error showed by CVS after checkout.
I can verify, that direct checkout of sources of tag cpplite_dev6 is not possible. I was NOT able to do (assertion was shown): cvs checkout -rcpplite_dev6 cpplite I was able to do: cvs checkout -rBLD200109270100 cpplite cvs update -A -d -P -rcpplite_dev6 cpplite
I have met with our CTO, our VP of engineering, our manager of tools, and our CVS developer to discuss this issue. We are still working on scoping the problem.
*** Issue 16266 has been marked as a duplicate of this issue. ***
We're working on a group of fixes to this- the following is a very tentative plan. Initial end-user workaround (in place) (PCN5875): using tag Initial technical workaround (PCN5875): Set up cvs so that it will work with *either* root. Interim solution (PCN5949): Have allow-root via CVS Pserver map to the real root under the covers. All strings returning to user via pserver normalized to complete the mask. Final solution: Subversion handles sim-links transparently. Again, this is tentative, and I am still getting ETAs for these.
I forgot to mention, that the issue 16266, which has been marked as duplicate of this issue, is about "cvs rdiff" command.
We are testing the initial technical workaround, and will update when it is ready for your testing on our staging server.
Moving this up to P1 to reflect its status as our highest priority support issue.
We have the initial workaround up on our staging server (stage3.sny...) Michael and appropriate others, could you take a look at this today to see if it meets your interim-term needs? Thanks.
Our developer updates: To be clear about the technical workaround, here's an example, using rtag. This *still* doesn't work: CVSACCOUNT=:pserver:taska@stage3.sny.collab.net CVSROOT=$CVSACCOUNT:/cvs cvs -d $CVSROOT co nbbuild/tagref cvs -d $CVSROOT rtag test_tag nbbuild/tagref This does work: CVSACCOUNT=:pserver:taska@stage3.sny.collab.net CVSROOT=$CVSACCOUNT:/usr/local/tigris/data/helm/cvs/repository cvs -d $CVSROOT co nbbuild/tagref cvs -d $CVSROOT rtag test_tag nbbuild/tagref
Command cvs -d :pserver:anoncvs@stage3.sny.collab.net:/usr/local/tigris/data/helm/cvs/repository rdiff .... seems to be working.
RE: Beside the Rdiff tests, are there other CVS tests we should run to make sure that the changes made didn't break anything else? We've had poor history with CVS changes and I want to make sure we install something that won't break what we already have again. Michael
I have no <Tag> access, cannot verify for now :-( Taska, would you help me with proper access to that site please? cvs rtag Rudolfs_test_tag nbbuild/tagref User rbalada doesnt have <Tag> access to project nbbuild cvs [rtag aborted]: correct the above errors first!
Rudolf, your user (rbalada) only had Registered User access on the site; it was not a member of the nbbuild module, nor did it have the "grandfather" permission. I gave it the "grandfather" permission, so you should be able to tag now. Michael Boyer is a Domain Admin on the staging server; in the future, if you need any additional permissions changes, he may be able to help you more quickly than I can.
Taska, I didn't see Michael in his dark office, so I decided to ask you instead of Michael. I can confirm that I was able to do rtag on stage3.sny with changed CVSROOT's directory path part. With usual CVSROOT it was unsuccessful as expected.
Rudolf: thanks for the confirmation. We're now making plans to update the live site; will update here on what the plan is and whether it requires downtime.
We've updated the live site (no downtime was required). Please verify that rtagging works with the long pathname.
Doesn't anyone want to verify that rtagging works with the long pathname on the live site? Reopening to track PCN5949. PCN5949 is internally slated for SC1.3. (That doesn't mean that we're necessarily going to have to wait for an upgrade of the NetBeans site to 1.3 to get this; it's just where the fix will first show up in a standard release.)
Moving to P3 because workaround is complete. Please verify that you can rtag now.
Rudolf, or someone else cc'ed here, please verify.
I just attempted to perform the same steps described in the initial report and got an assertion that appears identical to the one Rudolf reported.
To paraphrase the developer from up above: This *still* doesn't work: CVSACCOUNT=:pserver:taska@cvs.netbeans.org CVSROOT=$CVSACCOUNT:/cvs cvs -d $CVSROOT co nbbuild/tagref cvs -d $CVSROOT rtag test_tag nbbuild/tagref This does work: CVSACCOUNT=:pserver:taska@cvs.netbeans.org CVSROOT=$CVSACCOUNT:/usr/local/tigris/data/helm/cvs/repository cvs -d $CVSROOT co nbbuild/tagref cvs -d $CVSROOT rtag test_tag nbbuild/tagref
I can verify, that rtagging with long path CVSROOT on live site is possible.
although a workaround is possible I still want this issue to be fixed ASAP. Rationale: it's a regression, it affects basic functionality of CVS, it's painful to communicate it well to developers. <personal> Waiting for the "Grand Unification Theory" to be found is not a solution for me. </personal>
I agree Trung. We are working on this.
*** Issue 18107 has been marked as a duplicate of this issue. ***
Sorry, but have to increase the priority, since this is important functionality for comparing sources on different branches. The workaround does not work any more! /usr/local/tigris/data/helm/cvs/repository: no such repository cvs rdiff: authorization failed: server cvs.netbeans.org rejected access to /usr/local/tigris/data/helm/cvs/repository for user anoncvs cvs rdiff: used empty password; try "cvs login" with a real password $ runcvs -d :pserver:anoncvs@cvs.netbeans.org:/usr/local/tigris/data/helm/cvs/repository login (Logging in to anoncvs@cvs.netbeans.org) CVS password: /usr/local/tigris/data/helm/cvs/repository: no such repository cvs login: authorization failed: server cvs.netbeans.org rejected access to /usr/local/tigris/data/helm/cvs/repository for user anoncvs
Increasing to P1. diff is not reliable for added/removed files. Working rdiff is necessary.
Sorry about the communication misfire. The "long pathname" changed when we added an NFS mount to increase the space available. I created issue 19468 to communicate this, but unfortunately I seem to have copied the wrong people on it. Here's the new pathname: /shared/data/helm/cvs/repository Please see issue 19468 for more information, and please update this issue if you have additional concerns.
Martin, I've forwarded you an email from Taska's issue 19468 on Jan 16 (Wednesday last week). Decreasing priority back to P3.
This is O.K. while the workaround exists... Thanks.
*** Issue 19416 has been marked as a duplicate of this issue. ***
Administrative Change; SC1.3 has been renamed SC2.0.
This has been targeted for the Truckee 1 release of SourceCast. During the upgrade to that release we can verify or reopen if necessary.
*** Issue 35253 has been marked as a duplicate of this issue. ***
Updating..
Still not fixed: cvs server: Diffing openide/loaders lock.c:222: failed assertion `strncmp (repository, current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0' cvs [server aborted]: received abort signal lock.c:222: failed assertion `strncmp (repository, current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0' cvs [server aborted]: received abort signal Workaround does not work: /usr/local/tigris/data/helm/cvs/repository: no such repository /shared/data/helm/cvs/repository: no such repository When do you plan to fix this???
Setting dependency on P2/TASK issue 56539. Please resolve this issue by completing issue 56539.
Correction: Setting dependency on P2/TASK issue 56359. Please resolve this issue by completing issue 56359.
cc'ing ppl directly in case Collab has not yet seen this issue (in light of Brian's comment about email problems in issue 56722).
The repository path is now: /shared/data/ccvs/repository
Jack, Rudolph, Based on Brian's update on the CVS repository path, the workaround should now be working fine. Hence reducing the priority to P2. Also, the issue was originally opened as a defect. While I do understand that this is a desirable feature, it should have been classified as a feature or an enhancement from the beginning. Currently this is a known limitation within CEE, which is documented ("...it is not possible to use the 'cvs rtag' command with repository paths that are symlinks.") I will investigate more(before marking this as WONTFIX), but suffice to say that there are no milestones defined for this yet.
Release notes on the netbeans.org site has this documented. http://www.netbeans.org/scdocs/ReleaseNotes#whatis ->Version Control To use the CVS rtags, rdiff, and rlog commands the full path must be provided. Please contact your CollabNet support contact to obtain the full path for your site.
It looks like Brian forgot to mark this issue RESOLVED FIXED. People who know this issue in more detailed way can treat it *personally* as a FEATURE. Please note, that when the repository path is changed next time, the issue seen by users is a DEFECT, not FEATURE a thus it would be appropriate to reopen this issue as DEFECT. The user is a master and it's a DEFECT from user's point of view.
*** Issue 57574 has been marked as a duplicate of this issue. ***
Verified
We recently moved out from Collabnet's infrastructure