Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-dev] CVS problem: unable to Team -> Share Project...

 Peter, I had just submitted this as a heads up to the cvs list last week.  I'll re-paste it hear for you:
 
Eclipse failed for us when I upgraded to 1.11.9.  Eclipse is aware of problem.  The patch I implemented is found on Eclipse's Bugzilla page.   Here's how: 
1) (see second link provided in this email, scroll 1/4 down, see the attachment box.  
2) You'll find a cvs.jar.
3) Download
4) Shutdown Eclipse
5) Copy cvs.jar to "[eclipse install]/plugins/org.eclipse.team.cvs.core_2.1.1"
6) Start eclipse.
It solved the inability to view projects under HEAD, but none of the developers could get it to actually branch, etc.  ( I haven't had time to test this out myself, will do so soon. )
 
Below is a summerization and a link to the basics of the problem.
After that, a link to the specific bug page.
 
Why doesn't Eclipse 2.1.x work with CVS server versions 1.11.7 and beyond?
Most of the interesting Eclipse CVS functionality relies on the format of the
messages and the change in format made in 1.11.7 breaks the parsing in 2.1.x. 
See bug 45138 for more information on this issue.
 
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=45138
Bugzilla Bug 45138    
[2.1.2 Candidate] Eclipse doesn't work with cvs server version 1.11.9
 
-R


Peter Wyngaard <peter@xxxxxxxxxxxx> wrote:
Under both versions 2.1.1 and 3.0M4 of Eclipse, I am unable to use the
"Team -> Share Project..." wizard to import new files into a CVS
repository. I always get a "Remote Project Exists" dialog error, even
though the module name/directory name does not exist on the CVS server.

I've been a bit stubborn about tracking down this problem, and managed
to get Eclipse running under the debugger in Eclipse, and I think I
have narrowed down this problem.

Evidently, the SharingWizard checks to see if the ICVSRemoteFolder
("JanesTeamProject", for example) exists. On my setup, exists always
returns true, even if the folder does not exist in the cvs repository.
Exists is looking for a DOES_NOT_EXIST CVSStatus. This is set when the
appropriate cvs server error response is received (e.g., "skipping
directory"). The cvs server error responses appear to be parsed by
UpdateListener, who calls getServerMessage to aid in parsing the cvs
server error responses. getServerMessage uses the SERVER_PREFIX
constant to remove the prefix on the cvs server error responses.

This is where I believe there may be a problem.

Some sort of "cvs update" is performed to check for the existence of
the directory in the CVS repository. On my setup, here is the CVS
response that is received when performing this cvs update on a
directory which does not exist:

E cvs update: Updating .
E cvs update: cannot open directory
/usr/local/cvsroot/PetersTeamProject: No such file or directory
E cvs update: skipping directory

The UpdateListener does not throw a DOES_NOT_EXIST exception, even
though it should. This is because getServerMessage is returning null,
since SERVER_PREFIX is "server: ", so none of the error lines above are
being properly parsed, detected, and handled.

Actually, that's not really true. The ERROR_LINE status is returned,
but exists returns true anyway, which is arguably a bug in itself
(silent failure).

Looking at the CVS source (error.c), it looks like all error messages
are of the form "cvs ${command_name}: ${error_text}". So, I'm confused
why the getServerMessage() method is looking for CVS error lines of the
form "cvs server: ".

Did the text of CVS server error messages change at some point? I'm
using cvs-1.11.9.

Here is my setup:

OS X 10.2.8
cvs-1.11.9
java-1.4.1
Eclipse-3.0M4

Sorry if I'm way off track with all of this. If this is not an Eclipse
bug, I'd appreciate any help/advice.

Respectfully,

Peter

_______________________________________________
tools-dev mailing list
tools-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tools-dev


Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Back to the top