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've noticed that afte the migration the cvs server started returning weird stuff on cvs status command. Please see the inserted output of the status command. The weird part is the Repository revision line. there should be the repository patyh in the following format /cvs/javacvs/src.... however instead there's /usr/local/tigris/data/helm/cvs/javacvs/... Can this be fixed? Milos Kleint =================================================================== File: RemoveTypeComparator.java Status: Up-to-date Working revision: 1.4 Repository revision: 1.4 /usr/local/tigris/data/helm/cvs/repository/javacvs/src/org/netbeans/modules/cvsclient/commands/remove/RemoveTypeComparator.java,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
Internal CollabNet issues: SCS115, PCN4936.
*** Issue 13446 has been marked as a duplicate of this issue. ***
well, this problem appears after migration of cvs server which now returns file's path in a different format. But frankly speaking fixing it on server side will solve it only for this case, but what will you do if there exists similar problematic cvs servers around the world. Wouldn't be better to try to solve it on the client's side to? What do you think?
Well, I can not do anything with this. If you tell me, that the repository is at /cvs and the server returns the repository path as /usr/local/tigris/data/helm/cvs/repository/... then I can not know, that "/cvs" and "/usr/local/tigris/data/helm/cvs/repository" is the same physical location.
OK. You're right, sorry for that (I wrongly thought that it might be similar with earlier entered bug for commit.)
Can we get clarification on the problem? How is having a complete path affecting your work? Is iti a bug?
We have a CVS module in NetBeans, which is a wrapper upon cvs.exe client. We use "cvs status" command to get the information about files including repository path. When the user enter the repository as "/cvs" and the server returns "/usr/local/tigris/data/helm/cvs/repository" instead, we're not able to get the correct file repository path, which is necessary for other operations. I will appreciate if this inconsistecy could be fixed.
Thanks for the extra information. The developer has designated this as a defect and is implementing a solution.
Accepting.
I've got another case when this causes trouble.. cvs add on directories when using the javacvs client. it returns the collab path instead of the netbeans repository path. we listen for the message saying that he directory was added and populate the CVS admin files on the behalf of this message. That way the admin files get broken. the cvs comamnd-line works fine. I admit it's aprtly our (javacvs) problem as well, however it's definitely not something that standard cvs server would do either. I guess it's the responsibility of the wrapper to change the paths everywhere..
Successfully tested on staging. Determining when to push live.
Netbeans-specific stage will occur on Tuesday.
This was staged and brought live- please verify.
O.K., it works right now.
it still doesn't work for the cvs add command when adding directories.
Thank you for the update; accepting this, will speak to developer.
Several commands are being noticed to return the long repository path (/u/l/t/d/h rather then /cvs). These include: add commit diff update Fixes are being worked on at the moment (collabnet pcn5313). Estimated timeframe of 2 weeks for developer work because all fixes need to be reconciled with the open source version of cvs, not just fixed in the current version of cvs on the site. This time frame includes unit testing. As we get closer to the fix we will schedule time for creation of the rpm and ops to deploy to staging. Once on staging we request that you review and run any scripts that need testing. We will schedule a preliminary date for operations to push to production and confirm that date following netbeans team approval.
Ready for QA. Requesting promotion to staging and QA resources.
The protocol between pcheck and pserver has been modified. As a result,engineering recommends that the pcheck and pserver be put into the same RPM. This fix is going to staging and will be promoted, following successful testing, to production with 13383.
The planned resolution date for cvs issues is now: by Friday, Sept 14. Please see issue 13383 for details.
Here is some additional information on our rollout plan for these fixes: Additional engineering unit testing regarding suite of CVS issues to be completed by August 31. Full QA test with SourceCast Release 1.1 to be completed by September 10. Testing on stage to be conducted September 12 and 13. Targeting push to production on September 13.
Administrative note: Internal CollabNet issue number PCN5651.
Per NB IZ Issue#: 13383, ------- Additional Comments From Taska 2001-09-05 17:15 PDT ------- Conducted an internal meeting concerning this issue, resulting in the following schedule changes. Quality assurance has requested an additional day to test the interactions between our new RPMs and the current environment. Therefore, I propose that (assuming testing goes well) we promote the RPMs to the live site during the afternoon (Pacific time) of Sunday, September 16, so that they will be ready for the morning of Monday, September 17, European time.
*** Issue 15216 has been marked as a duplicate of this issue. ***
At this time, we are still waiting for the go-ahead from our quality assurance department that 1.1 is ready. We currently estimate that we will be ready for final fix promotion sometime next week.
Status summary: We are waiting for our QA team to put final approval on SC1.1; their testing is being held up because of operational problems with our Solaris test box. SC1.1 is destined to be our inaugaral Solaris version, and until it is approved on Solaris, it can't be released. In the case of lack of progress on Monday, we will be meeting to determine next steps.
This evening, our release engineering group packaged what we hope to be the final release candidate of SC1.1, and our quality assurance group has already begun work on testing it. More details tomorrow.
We have found and fixed one more bug, and a new (once again, hopefully final) release candidate is being produced. I will continue to update as we hear more.
We have finally released SC1.1, and the CVS rpm from that version is being moved onto our staging box today. Our plan is to test this tomorrow and friday, and to implement it on Sunday evening our time. We will be confirming this in the Thursday morning/evening support call.
The cvs package has been installed, and our qa department has begun site-specific testing.
CC'ing Honza to have an overview of this issue (which causes also problems to our CVS support modules in IDE)
Our qa team has finished their testing, and the sun netbeans and forte for java folks are doing their testing. If no objections are raised by Saturday morning, Pacific time, our operations team will make the change on the live site on Sunday night.
We have been given the go-ahead; upgrade will happen on Sunday evening, Pacific time.
Upgrade is complete.
hmmm....seems it is finaly fixed. marking it as verified
Target milestone was changed from not determined to TBD
We recently moved out from Collabnet's infrastructure