Eclipse CVS Issues And Workarounds

There are a number of issues with Eclipse that we have been running into and they all appear to be related to integrated CVS feature. We'll be using this post to keep track of these issues and mention any workarounds and/or bug fixes that we may find.

  1. ActionScript files are seen as *binary* by default. We have our suspicions that this may be somehow related to Flash MX 2004 Pro environment being registered as the default application for AS files.

    Workaround: We need to specifically tell Eclipse that AS files are ASCII. Go to Window -> Preferences -> Team -> CVS -> File Content and click "Add". Then, add "as" as the extension and ASCII as the contents. Do this before you add any files to the repository. I haven't had any luck with the Team -> Change ASCII/Binary property setting for AS files already in the repository.

  2. (a) Java compares (diffs) do not work (regardless of which two revisions of a file you are comparing, it always appears as if you are comparing the compared revision to an empty base revision) and (b) Eclipse refuses to compare revisions for .AS files, seeing them as binary and giving an "Internal Error"

    Solution: We found that all of these problems were due to one thing: Our CVS server's version. We were running version 1.10 on OS X. According to the Eclipse CVS FAQ, Eclipse only supports CVS versions 1.11.1p1 or higher. Upgrading to version 1.11.2 fixed these issues. [Note: I am now wondering if our original issue with .AS files being seen as binary (see above) was related to this.]

  3. Projects checked out by eclipse on to Windows machines appear as if they've been checked out on Unix. Yes, it is as weird as it sounds! Using Eclipse M5, checking out a project from CVS results in a sandbox that cannot be used by TortoiseCVS. The error given is "This CVS sandbox may be for Unix, not Windows . . . This can cause problems. You should check out a module under Windows to use it with Windows, or under Unix to use it with Unix . . . Alternatively, this error can be caused by a CVS\Root file which is corrupt for another reason. This check looks for a carriage return and a line feed as the last two characters of the file."

    Comparing the CVS\Root file with the one from the same sandbox checked out by Tortoise reveals that the line ends do, in fact differ. I am looking into this to see if this is the sole reason for the bug. If so, it can be easily patched.

    Workaround: There is an open bug on this (#48137) over at the Eclipse project with further information. At least part of the issue stems from the line-endings for the CVS meta files saved by Eclipse (they are in Unix format). Removing these, however, still doesn't fix the problem. However, this is a warning and can be turned off in Tortoise CVS (Preferences -> Advanced -> Check not Unix sandbox.) I don't know however, if this will have any ill effects if used with the meta files saved by Eclipse (e.g. CVS corruption). I would think not but, for the time being, I won't be mixing the two!

    Update: This bug is now assigned to be fixed in Eclipse 3.0 M8. (We're currently on M5).