Line ending translation extension

[toni.arte at nokia.com]

>> Hooks won't fix the problem. They will just escalate minor style
>> annoyances to showstoppers. That might be good in some setups with
>> some policies, but I would rather not work such a place where
>> someone else operates the clue stick.
>
>I'd rather have more hooks than less (spaces at ends of lines? BZZZT!
>Tabs?  BZZZY!)
>Pretending that there are no standards is less useful than having as
>much automation to enforce them as possible, but it sounds like you
>only work where you are the only one setting policy. I don't have
>anything further to add under the circumstances, my experience does
>not apply/translate your situation.

I only see this kind of hooks as a major annoyance to the end-users. There should be a way to configure the system to silently do the 'right thing' (TM).

The big question here is that on heterogonous environment, do you convert all EOLs to the same format, or do you allow some files to have different encoding from the others. Or do you care at all...


I've got some vested interest on this, as Nokia is opening up the Symbian OS and the S60 platform through the Symbian Foundation, using Mercurial as the SCM solution. Internally we have a different SCM solution (IBM Rational Synergy, ex. Telelogic Synergy, ex. Continuus). For us the problem is that Synergy cares about the EOL's, and we'd really like to have the 'right' EOLs on the Synergy databases on Unix. Now if we synchronize data back and forth between Nokia and the Foundation, we get data which doesn't obey our conventions in Synergy. Right now it does not matter much as Symbian & S60 is only built on Windows, but anyway having CRLF EOLs on Unix is not the 'right thing'.

I was studying this problem a few months ago, and at least back then there was no ready-made solution:
* Synergy will always assume a file on Unix/Linux has LF EOLs and performs no conversion between the work area and the repository. On Windows it will always perform the CRLF<->LF conversion between the work area and the repository
* Mercurial (out-of-the-box) only supports the encode/decode settings on a user-maintained file, so everything is up to the end-user. No settings inherited from the cloned repository
* Git has '.gitattributes' which is cloned as a part of the repository, so the special settings can be inherited. The funny thing here is that if you set the EOL style on .gitattributes, it will only affect your work area once you have first populated it. The reason for this is that the .gitattributes is read from the work area once it's been first populated.

What I'd really want to see is a solution where the 'master repo' (or whatever you call it, anyway the initial repo people clone the project from) could set up some sensible defaults for the repo, and that the users would not need to do *anything* to have their contributions in the right EOL format, whatever the project has chosen to follow. I only see this happening when an extension like hgeol gets included into the core Mercurial (and when most people are using that version).

Here's some further reading: http://blog.symbian.org/2009/05/13/a-dilemma-at-the-end-of-the-line/ 
--
Toni