0

I have a couple of libraries that are built for Linux and windows. The Linux version builds via a Makefile in the root directory, and the Windows version is a Visual Studio 2010 project that uses the exact same source files. Platform-specific code is handled in a hardware abstraction layer header (.h) file which handles things like strtok_s() versus strtok_r(), Visual Studio's C89 limitations, etc.

In order to reduce the headache my devs have when dealing with SVN, I ran a batch script on a Linux box to convert the line endings for all the source .c, .h, and .cpp files to Linux (LF), set the svn property for line endings to "native" (ie: svn propset eol-style:native), and commited all the files in one large commit.

No issues on the Linux side of things, but whenever the Windows users check out the file (they are using TortoiseSVN), make changes, and generate the diff/patch, TortoiseSVN complains about inconsistent line endings. I verified with GVim on Windows, and it seems the files all have UNIX style (LF) line endings, but the portions of the file that was changed in Visual Studio has Windows style (CR/LF) line endings.

In Visual Studio, I've already manually saved the files as "Unix Line Ending" via the "Advanced Save Options" dialog, but this setting doesn't appear to persist after SVN commits, which leads me to suspect that no actual file options are saved in the Visual Studio project file (.vcproj) or solution file (.sln), but the encoding of the source file itself is just changed, and isn't preserved on our SVN server.

How can I just set-and-forget line endings for cross-platform projects like this, or get Visual Studio to stop messing up the files? It was to my understanding that setting the EOL-style to native meant that clients check out files in the system's native encoding, and it's stored in a "preferred" format on the SVN server, so I wouldn't have to deal with these issue.

Thank you.

Cloud
  • 18,753
  • 15
  • 79
  • 153
  • `eol-style:native` should suffice. Your comments point to an issue with your Tortoise client (check for known issues relating to your version, but i doubt that's it), that should convert all the `LF` s in `CRLF` s. **But**, VStudio (I am using ancient 2k10) doesn't mess with _eol_ s. It preserves the original file _eol_ (and for one that has `LF` s it keeps it that way - even when copy/pasting `CRLF` ending lines). I think that there is a _eol_ miss in one of your files. Just delete&&re-add one file from a _Ux_ box (making sure that there are only `LF` s) and see if it still fails on _Win_ . – CristiFati Sep 09 '15 at 22:49

1 Answers1

1

Setting the eol-type property to native should be what you need. The command for setting end-of-line conversion is svn propset svn:eol-style native yourfile.c. If you used the exact propset command that you show in your question, then using the syntax I listed should solve your problem. If the command in your question was just a typo, then here are a few things to try if you're still having problems.

  • Make sure that your Subversion clients are set to up automatically add the eol-style:native property to new files (command-line, TortoiseSVN). Otherwise, you'll run into this problem again whenever new files are added.
  • Check out a fresh copy of the repository on a Windows machine. Before letting Visual Studio touch the code, verify that the line endings are all Windows-style. Use Visual Studio to make some changes, then check the line endings again. If they're not all still Windows-style, then Visual Studio is the culprit. Check your settings and make sure it's not leaving files as-is and not trying to do any sort of automatic conversion or re-encoding.
  • Check out the code on a Linux box and use the file utility to inspect each of the source files. The output will show what sort of file endings are used. Ensure that none of your files are reported "with CRLF, LF line terminators". This means that both types of line endings are present, and Subversion's auto-conversion won't always work properly. To resolve this, use the dos2unix utility.
bta
  • 43,959
  • 6
  • 69
  • 99