Community
Participate
Working Groups
Case: Repositories (same server, happens on both repositories) 1. e:/repository1 2. e:/repository2 Projects (created via 'checkout as') 1. repository1/src/ checkout as one 2. repository2/src/ checkout as two All is well until you try to check in the .project and .classpath for each of the projects. Then it yields the error listed above. My search on the net revealed that you can recreate this error by trying a 'cvs update' on a directory that exists on a different cvs server...not sure it that helps any. This error is experienced when synchronizing, as well as in the cvs repository navigator. Click on HEAD and the same appears ( you cannot browse at all ).
Presumably according the paths in your example this is logged against CVSNT, which is unsupported. Please provide: - build # - CVS server version and type (I assume CVSNT from your repo path) - any relevant info in .log Q: Did the projects already have .project's in the repo at the start of your "check out" step? I have tried your steps (assuming the answer to my question above is 'no') against CVSNT 1.11.1.1 with no problem Since you fail on expanding HEAD the indication is that there is something fishy in the repository location. I don't believe this has to do with the fact you have to locations/projects in your steps. Q: Can you test whether you get the error if you've removed one of the locations and projects? (According to my guess you still will). Q: Are the paths for your repo locations absolute/fully-qualified? Marking post 2.0 for further investigation.
- build # >>>06022002 F2 - CVS server version and type >>>CVSNT 1.11.1.3 - any relevant info in .log >>>nothing shown Q: Did the projects already have .project's in the repo at the start of your "check out" step? >>>One project did. Q: Can you test whether you get the error if you've removed one of the locations and projects? (According to my guess you still will). >>>to be done, i'll get back to you Q: Are the paths for your repo locations absolute/fully-qualified? >>>yes Also, I have been reorganizing the cvs quite a bit from within Eclipse. Sometimes it was a copy, paste and commit, other times it was a move, then commit. My repository has been up and running for a couple of months with no problems using netbeans. I believe Eclipse is a superior ide, so hopefully I can get it ironed out. I believe it has something to do with Eclipse or it's working files because WinCVS has not problem, nor does netbeans. I've also done a Team Project Export, killed eclipse altogether, then reinstalled (same version), and imported the team project. No dice.
Latest findings: 1. CVS files in workspace from a different repository 2. Once I get the noted error, the CVSNT server is closed for business, until the entire server is restarted (not good, but definitely a server issue). 3. Old project's (now subdirectories) .project, .classpath files CANNOT be removed through Eclipse. Does this indicate some issues with the copy/move functionality?
Recreated Bug: 1. Create two java packages: com.a and com.a.b 2. Create two java classes in com.a.* 3. Refactor | Move on a java class to com.a.b 4. Team | Synchronize with Repository
Reopening
Not reproducable on CVSNT 1.11.1.3 and Eclipse 2.0.1 --------------- Versions --------------- Eclipse Platform Version: 2.0.1 Build id: 200208291828 Relevant Plugins: CVS Team Provider Core 2.0.0 CVS Team Provider UI 2.0.1 ----------- CVSNT cvsnt_1.11.1.3 CVSNT 1.11.1.3 (Build 57i) ----------------
Kevin Ross, can we close this now since its been indicated the bug is no longer reproduceable?
I have since switched to cvs on Linux. I believe that upgrading to Eclipse 2.0.1 fixed any issues with this error, since other side effects went away as well.
