All the Windows files you touched now seem to have a line ending issue.
How I can solve this?
Every time a UNIX-based committer receives files from somewhere
else (for example Buzgilla Patch or another project) then they
need to ensure that they do not have a Windows problem. Do a 'dos2unix' on the files to fix them.
For a Windows-based committer, they may need to do the opposite (i do not know) and they definitely need to ensure that they have a proper CVS client that converts the line endings to the UNIX-style on commit.
From the latest commit messages I found another reason for a line ending issue: many text files were committed as binary files and are so an almost guaranteed source of line endings problems. When committed from Unix David's line endings test is passed, but you can't view the files in Windows in little editors like notepad. When committed from Windows David's test fails, he fixes it and you can again not view the files in Windows. The problem is that binary files remain untouched when committed to CVS and so the line endings that the CVS client should handle in theory.
What's the stuff in CVS? It's called keyword substitution and for binaries the value is set to -kb, for ASCII you have different possibilities (keyword replacement, keyword expansion, keywords untouched and some more), I simple chose the Eclipse default -kkv (expansion). I don't know how to do this from command line, but I guess simply by committing with the additional -kkv. I chose Eclipse (Team > Change ASCII/Binary Property) and it was a bit of manual work (I felt like in the game Diablo: click & fight, but here where no monsters, only binary files ;). When adding 'CVS' to the label decorations (which I have done to see easily which files are locally modified) you also see whether the files are ASCII or binary - you only have to open and close all directories. It would be good to get this work done automatically, or at least the list of all binary files.
What can be done in future: Configure your CVS client correctly. From the blocks and their initial committers you see problem candidates:
woody > htmlarea Ugo taglib portal, portal-fw Carsten ojb Antonio linotype Stefano eventcache Geoff
We must not add files with (for the server unknown) file endings add "automatically", you must add them ASCII style (I know WinCVS has this explicitely, but I don't know about Eclipse). Another option is of course to set the file styles server side, but I don't know if we can do it for every file ending (imagine the files in legal), but at least for CSS, JS, XMAP, XROLES, XCONF, etc.
If David has observed the commits more deeper I guess many files were known to him for dos2unix commits. When paying attention to the ASCII/binary issue we will exempt him from this work to a certain extent and he can invest his time on real Cocoon or Forrest features :)
Joerg
