Line ending translation extension

Adrian Buehlmann adrian at cadifra.com
Sat Sep 12 07:14:07 CDT 2009


On 12.09.2009 06:56, Stephen J. Turnbull wrote:
> I guess that the default should be <Windows text file> = native.  This
> works well because all text files will default to native on checkout,
> and thus on Windows they'll all have the right EOL *even if created on
> Unix and the user doesn't remember to specify "<file> = windows" in
> .hgeol*.  Users who actually need CRLF on non-Windows platforms (eg,
> users who build a Windows version using Wine or administer a Samba
> server on Unix) would have a separate "cross-platform" branch where
> the .hgeol specifies CRLF.  I'm not sure how this would work for
> people prefer LF even though they work on Windows (hi, Paul!).

Not sure if this is really relevant here, but, as an example,
on the TortoiseHg project we simply store all files in LF, even though
one of our main target platforms is Windows and most contributors
use Windows to hack on TortoiseHg (although that's a rather small
group anyway and TortoiseHg is a small project too).

I remember that we had some issues in the past with files
having random mixed LF / CRLF line ends, causing some troubles I can't
remember any more.

Since we switched almost all source files to use LF line ends only,
I haven't heard of any problem ever since. Contributors send patches
to the -devel mailing list, and these are applied without problems.
The TortoiseHg sync dialog makes it easy to send these patches,
even for Windows users. I use that dialog myself too.

We have sources written in Python (dialogs) that are used
for the Windows and the linux target, and we have C++ sources
used for the shell integration target on Windows only.
Almost everything is LF only (with the exception of a couple of files
like *.sln, *.vcproj, etc., which are CRLF).

As an example, I use notepad++ as my main editor on Windows,
and it handles LF line ends perfectly fine.

I also use Visual Studio C++ 2005, and this one handles LF files
fine as well.

In short, I recommend to agree to using LF line ends for any
project that does cross platform development. It's simple and
solid and doesn't require awkward extensions that tweak files
on check-in.

Personally, I would never ever use any piece of software that
dares touching my file contents during checkin. From a VCS,
I expect to check in exactly what I have on my disk in my
repo, nothing else. And I want to get the exact same back
on checkout, no matter on what platform I currently have
my repo.

On a larger project, I could imagine having hooks that check
that files meet project standards (e.g. *.py files
having LF line ends for the TortoiseHg project).


More information about the Mercurial-devel mailing list