End-of-line issues between Windows and Unix & eol.py

[toni.arte at nokia.com]

Hi all,

Martin Geisler has done an awesome job with the EOL extension for Mercurial. But there are a couple of changes/enhancements I would like to propose:
1. Do not care about the 'inconsistenteol' at all, i.e. if there are lone CR's in the file, let them be there.
2. Change the CRLF pattern from string '\r\n' to a regexp '\r+\n'.
3. Drop the support for Mac OS '\r' eol.

We are currently using the eol extension when synchronizing the Symbian code from Mercurial into our commercial SCM system. This system happens to care about the EOL's, and really expects to find unix EOL's on text files on Linux (or Solaris).

Since Mercurial is a distributed system, we don't really have control over the settings the developers are using, and I don't really believe that denying commits by having hooks in place is the right answer. With this eol extension we can guarantee that the working directory of the data which is synchronized into the commercial system is in the Unix EOL format (the other option would have been to run the synchronizer on Windows instead of Linux or Solaris).

The reasoning for the proposals are:
1. We need a fully automatic system. Having lone CR's is a lesser evil than having automatic syncs which fail because of this.
2. For some strange reason we have found a lot of files with '\r\r\n' as EOL. At least the Windows 'rcp' command does this if you use the '-a' switch to copy a DOS format file, although I think the real reason is something else. Anyway, files which are double-converted to DOS EOL's.
3. Mac OS X uses Unix-style EOL's. Mac OS 9 was the last major OS having this EOL style, and it was discontinued at 2002.

With the EOL extension all we need is to:
1. Have the 'eol' extension enabled on the system which runs the synchronizer.
2. Have the .hgeol file created on the root directory of each repository, with this content:
---
[patterns]
** = native

[repository]
native = LF
---

The source code of the EOL extension is here:
http://bitbucket.org/mg/hg-eol/
--
Toni Arte

-------------- next part --------------
A non-text attachment was scrubbed...
Name: eol.patch
Type: application/octet-stream
Size: 1179 bytes
Desc: eol.patch
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100414/b39e92fb/attachment.obj>