Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
We have been using IBM WebSphere Application Developer 4.02 / Eclipse R1.0 with CVSNT, and have not been able to immediately browse newly created streams as can be done with unix versions of CVS. After spending some time working with the 57b source, I have hacked together a couple of fixes to compensate for some divergent behavior in CVSNT error handling. I have noticed that the latest server sources have been drastically changed, but it is not clear to me, however, that the new server code will address this problem. Consequently, I will describe my understanding of the problem and appeal to the author(s) of the new server code to allay my fears and/or test for and address this issue. When a new stream/branch is "created" in Eclipse, Eclipse simply creates a name for the stream/branch (which may be preexisting) and it shows up in the repository tree view. If the user then expands (+) that stream to see its contents, they should see all current projects/modules in the repository. With unix CVS, this occurs correctly, but with CVSNT (through 57c) no expansion occurs. This forces users to engage in cumbersome workaround tricks to add a project to the workspace from the new stream (checkout). By using windump to examine the data exchange between Eclipse and CVSNT, and between Eclipse and CVS running on unix, I have determined that CVSNT is not returning certain error data that Eclipse depends upon. When a new stream/branch is first expanded, Eclipse sends (via remote protocol): Global_option -n Argument -r Argument streamname Argument -d Directory . cvsrootdirname Argument . update Since a branch tag for streamname does not yet exist in the repository, CVS (unix) replies: E cvs [server aborted]: no such tag streamname CVSNT will also send this reply, but ONLY on the very first execution of cvs.exe, successive tries will fail to return any error. Replacing the cvs.exe with a copy or a new build seems to unlink you from whatever external data is influencing this. I never found what precisely was causing this in the 57b source, but I "fixed" it by putting a sleep(1) at the beginning of server_cleanup() in server.c. After receiving the above error response from the CVS server, Eclipse further waits for the response: error This is the seemingly redundant piece of output written from do_cvs_command if resulting errs > 0 from command execution. /* We will have printed an error message already. */ buf_output0 (buf_to_net, "error \n"); It doesn't seem that this code is reachable for an abort severity error in the 57b source. Eclipse needs this response, however, before it will retry with the more general request: Argument -d Directory . cvsrootdirname Argument . update