Community
Participate
Working Groups
Mac OS X.2.4 Eclipse I20030220 I imported a project which I had used under Eclipse 2.1M5. The project was originally shared with CVS information, but the CVS tags showed up as Java packages (in the Java Browsing view). The CVS connection was using extssh to a CVS server which I independently verified using the CVS command-line tool that I could still use (so not due to the fact the CVS server could be connected). When I set it for sharing, it asked whether or not I wanted to use the existing CVS information. I did, and selected the 'Verify when finished', but it hung very shortly into the CVS process. Having waited for 10 minutes, I had to force-quite Eclipse because it wasn't responsive.
Created attachment 3650 [details] Screenshot of Eclipse hanging during import phase This showed how far the connection progress bar went; it may be useful in determining at what point the connection failed
Created attachment 3651 [details] Screenshot of Eclipse hanging during import phase This showed how far the connection progress bar went; it may be useful in determining at what point the connection failed
Created attachment 3652 [details] ROOT entry in CVS directory for project
I force-quat eclipse, and then copied over the .metadata from my previous workspace. When I restarted, the application worked as expected and I could use CVS to interact with it. It looks like the problem is in sharing an existing repository rather than repository access per se. I also got the build wrong; it was 20030221, not 20 as previously mentioned.
I checked out the same project using :ext: instead of :extssh: and it seemed to work fine when I'd checked it out as directly. It may either be a glitch in the :extssh: or the share mechanism...
Are you running cvs on MacOS X? What version? Apple's version is too old.
I'm using Mac OS X on the client, with SSH to connect to a Linux server. The CVS on the local path (Mac OS X) is /usr/bin/cvs (1.10) which I'm guessing is Apple's; under Linux it's 1.11.1p1. I should have said that I've been using CVS to share my files since Eclipse came out for Mac OS X with no problems at all up until I tried to 'Share existing project' with 2.1RC1. Instead, I dropped the project from Eclipse, then checked out the version from CVS as a project, and the synchronization/uploading/downloading etc. works fine. So it seems to be just a glitch in the share existing project, or something that depends off that ...
I've seen this behaviour since the M4 builds (up to RC1), even with "pserver" connection types. Last week I installed cvs 1.11.5 via fink, linked /usr/bin/cvs to /sw/bin/cvs, but Eclipse still showed no difference...
If I remember correctly, Eclipse doesn't support 1.10.x versions of CVS. It requires 1.11.x. So I'm using the Fink version of CVS (version 1.11.2) which works without problems. However, I'm not sure whether your problem is related to the CVS version.
From the Eclipse FAQ (admittedly from 2.0) 1. Does Eclipse use [WinCVS|CVS command-line client] to talk to the server? No. Eclipse implements a CVS client in Java that talks directly to the server using the documented CVS protocol. No external CVS client is required. http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-vcm-home/docs/online/cvs_features2.0/cvs-faq.html So I don't see why having any kind of version on the Mac should hit this issue at all. My CVS server is on Linux using CVS 1.11. Has something changed with 2.1 that uses the OS native CVS tool? In any case, extracting from a CVS server works, committing works, synchronizing works; it's just the sharing that doesn't.
I have tried many different combinations of sharing projects both with extssh and pserver and have not been able to reproduce this, therefore there is nothing I can do for 2.1. Moving to 2.2.
Does this problem still occur in RC2? If so, can you give us your exact setup (i.e. Mac model, processor speed and OS, JVM, CVS Server version)?
As far as I have seen it seems to work in RC2. In the meantime I have installed CVS 1.11.5 via fink which should now be used by default; perhaps this helped solving the problem...?
Tested against 2.1RC2 on Mac OS X.2.4 (client) Linux 2.4.18 (server). I have not been able to replicate this problem again. I suggest marking as 'WORKSFORME' and if I can not find a way of replicating this again under RC2 then I'll verify it later this week.
Verified as working under 2.1RC2 on Mac OS X.2.4
