[Changing the subject and hopefully appending this good stuff to the whitespace thread. Was: Re: cvs commit: cocoon-2.1/legal LICENSE.ant]
Joerg Heinicke wrote: > David Crossley wrote: > > > > 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. The -k option is only for 'add' and 'update' etc. The default with the command-line client is to do ASCII and you need to explicitly do 'cvs add -kb' for images, and jar files, etc. > 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. I had started a Perl script for another job and changed it to deal with this. It operates on the output from 'cvs log'. See the script on apache.org in my home directory ~crossley/bin/binarytext.pl I have run it on the "woody" block and cannot see any problems. Someone with more bandwidth could run it on the whole cocoon CVS. > 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. I have a big list of what should be a text file extension in the binarytext.pl script. Perhaps we need to change our license files to have a .txt filename extension. > 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 Thanks Joerg, for your important discovery and follow-up work. Yes i would rather work on "real" features, but i think that it is very important to have an efficient CVS, so i do not mind doing this type of work too. --David
