Roy Fielding wrote: > find . -name \*.java,v -print | xargs perl -pi -e 's/\r//g;'
so I did
ssh [EMAIL PROTECTED] mkdir ~/cvsbackup rsync -a /home/cvs/avalon-excalibur ~/cvsbackup cd /home/cvs/avalon-excalibur find . -name \*.java,v -print | xargs perl -pi -e 's/\r//g;'
and it seems this has indeed fixed the issue without further problems. Let me know when you see anything weird happening, or if there are other repos which need fixing.
Stefan Bodewig pointed out that ant has java sources checked in as binary, which kind-of makes it not a very good idea to do this conversion automatically on checkins.
For people on windows, I found this to confirm Terry's suggestion:
Luke Dunstan wrote:
"I was thinking about the option that someone mentioned in WinCVS that
prevents the line ending conversion, and I found that it works by setting the environment variable CVSUSEUNIXLF=1 (equivalent to passing the --lf option). This is an undocumented extension to CVS that is only included in the CVSNT client, which happens to be the client included as part of WinCVS and TortoiseCVS. So TortoiseCVS can be made to behave like MSYS CVS by adding the line "cvs --lf" to .cvsrc in the HOME directory or by setting the environment variable. Using the environment variable seems better if TortoiseCVS is configured to use the same HOME directory as MSYS because otherwise MSYS CVS complains about the --lf option. So the moral of the story is: never use the official CVS client, only CVSNT (www.cvsnt.org) can be configured properly."
so the request is for everyone on windows to set CVSUSEUNIXLF=1. You can do that through Start> Control Panel > System > Advanced > Environment Variables... if I'm not mistaken.
thanks everyone!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
