We have a large number of programmers on different platforms all using CVS.
We have developers using windows with TortoiseCVS (which uses cvsNT)
We have developers using ubuntu 8.04
We have developers who have two boxes Ubuntu and windows.
A wide range of different editors are used by different developers on different platforms.
And we are having huge problems with line endings. Which manifests as a continual growth in the number of line endings in the files.
Now as I understand it TortoiseCVS uses cvsNT which assumes UNIX line endings in the repository. When you check out it converts the UNIX line ending to windows line endings and when you commit it converts the windows line endings back to UNIX line endings.
In ubuntu the cvs clients does no conversions as the repository should be UNIX line endings and linux also uses UNIX line endings.
This all works fine provided everyone on windows uses a cvsNT based client. And no-one switches their OS.
Sadly people with Ubuntu and Windows boxes often switch and may checkout, edit or commit on different operating systems.
And as a result they end up committing a file using the linux CVS client which has windows line endings.
When this is checked out using a cvsNT client on windows the CRLF is converted to CRCRLF which appears as two lines. The more times this happens the more new lines appear in the file.
Is there a way to make CVS on linux convert any windows line endings to UNIX line endings on a commit to prevent this from happening. This way the CVS server will only have UNIX line endings.
Any other suggestion of ways to overcome this are also welcome.
Best Answer
An approach would be to require the development team to enforce line endings.
dos2unix and unix2dos on both linux and unix work great. cywgin on Windows will provide an implementation.
You could have a script that cleans up the line endings that people run before they check in.
My primary suggestion would be to either switch to another Version Control System or to turn off the magic line feeds. I have never had magic line feed conversions provided for me and my development teams have always had a standard encoding. It did not work perfectly, but it worked pretty darn well.
You could also write a simple script that would be running in a continuous integration environment scanning for updates that increase the line feeds. You could then either reject the change or clean up the issue.
Good Luck, Jacob