CVS line endings

Question

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.

Answer 1

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

Answer 2

The only reason I have seen for messing up line endings with CVS is if you copy file from one OS to the other. If you're doing this, you're manually circumventing the VCS. That's of course asking for trouble. So either stop doing this or remember to clean up after yourself.

I don't know of a way to automagically check or even fix this in CVS. Have you considered switching to SVN? It's pre-commit hooks might be a way to do this. OTOH, once you're in SVN land, with its the support for quickly creating and destroying private branches, you might as well never circumvent the VCS anymore: create a branch, on one platform check in your changes on that branch, on the other platform switch to that branch, and continue working there. Repeat until done, merge your branch into the trunk, and delete it. No sneaking of files from one machine to the other behind the VCS' back. One thing less to worry about.