Community
Participate
Working Groups
When checking out a branch from cvs within eclipse (ext or extssh), many of the jars (and the same jars every time i have tried) are missing between 1 and 10 bytes making them corrupt. I have repeated this on both the linux client and the mac osx client. Checking out with a comand line cvs works. I will attach a jar i checked out with eclipse with one i checked out with a command line client, both of which our using ssh for a connection.
Created attachment 4546 [details] Good jar Downloaded with command line cvs client on linux
Created attachment 4548 [details] Bad jar this jar was checked out using eclipse
I suspect the problem is that the files are not marked as binary (-kb) in the repository. To verify, select the file in the navigator and open the Properties page from the context menu. If the keyword mode is anything but -kb, then it needs to be changed using the "cvs admin" command. This needs to be added to the Eclipse CVS FAQ.
Your absolutely correct, many of the jars in the repository were not tagged as binary. Why is eclipse doing this while command line clients seem to get all of the bytes even if binaries are tagged as text files? This seems odd to me.
The reason is historic. Eclipse CVS (in Eclipse 1.0) used to store all files as binary which added spurious CR to all files that were committed from a CRLF platform. Code was added to collapse CRLF to the platform line-ending on checkout. This eases Eclipse 1.0 to 2.0 migration. I will check to see if Eclipse 1.0 to 2.1 migration is expected and, if not, look into removing this behavior. However, if your project was even checked out on a CRLF platform, the binary files run the risk of being corrupted unless they are flagged as binary.
I see, well we are going through today and doing house keeping on all binary files in cvs to fix this for eclipse users and for cvs compliance (this recent release 2.1 is swooning many of our emacs and jbuilder users over to eclipse, thats the sign of a great IDE) . Thanks for the update,
Lowering severity and waiting for confirmation that changing file keyword mode solves the file corruption.
updating those file to binary (-kb) solved the problem, if this is to be added to a FAQ you should also mention a quick way too update a large number of jars in eclipse is to multi select them in the Package Explorer window right-click on the highlighted jars and select 'Change ASCII/Binary Property' from the team menu.
Sorry I should have mentioned in the above comment to first copy the known good jars to your project (in place of the corrupted ones) then do the Binary property change.
I didn't mention the 'Change ASCII/Binary Property" approach in the FAQ for the exact point you just mentoned. Using the command-line client does not require the user to eplace the corrupt jar with a good one. It would be good to mention both approaches though.
Post 3.0
The Eclipse CVS client was changed during 3.0 such that it will no longer try to correct line endings. The behavior will match that of the command line client.
