Mercurial changing to autocrlf?

[Martin Geisler]

<toni.arte at nokia.com> writes:

> Yes, the 'hg-eol' is working very well for us. The use case is
> interworking with Linux and Windows, and we need to have certain text
> files on their native format on both OS's.
>
> The issue with hg-eol is that it's not a part of core Mercurial, so
> getting the right EOL's depends on the individual configuration. And
> yes, hg-eol is only active if the project chooses to use it:
> * the extension needs to installed and enabled
> * the project root directory needs to have a configuration file
>   '.hgeol' to describe how EOL's are mapped between systems, which
>   files are converted etc
>
> Right now we only use it to clean up the data to be loaded into our
> enterprise SCM system (this requires the data to be in Unix format
> when we are running our sync tools in Unix).
>
>
> I did propose a change a few weeks ago:
> http://selenic.com/pipermail/mercurial-devel/2010-April/020318.html
>
> I can't see the attachment in the archive, so here's my patch once more:

I'm sorry I forgot the patch the first time. Would you like commit
access directly to the Bitbucket repository so that you can fix such
things yourself?

You and Symbian seem to be the only "customer" so far, so I would very
much like you guys to be able to fix any problems. I'm adding Brett
Cannon since Python should also eventually be a user of this.

> ---
> # HG changeset patch
> # User Arte Toni (Nokia-D/Salo) <toni.arte at nokia.com>
> # Date 1271232685 -10800
> # Node ID 9fe4ef576d0659ed55282a359a01252c39d59692
> # Parent  22218cc9642a622f406aaa1186e090696c928721
> Change the tolf and tocrlf filters to allow multiple \r's before \n
>
> diff --git a/eol.py b/eol.py
> --- a/eol.py
> +++ b/eol.py
> @@ -14,20 +14,22 @@
>  # Matches a lone LF, i.e., one that is not part of CRLF.
>  singlelf = re.compile('(^|[^\r])\n')
>  
> +crlfre = re.compile('\r+\n')
> +
>  def inconsistenteol(data):
>      return '\r\n' in data and singlelf.search(data)
>  
>  def tolf(s, *args, **kwargs):
>      """Filter to convert to LF EOLs."""
> -    if util.binary(s) or inconsistenteol(s):
> +    if util.binary(s):
>          return s
> -    return s.replace('\r\n', '\n').replace('\r', '\n')
> +    return crlfre.sub('\n', s)
>  
>  def tocrlf(s, *args, **kwargs):
>      """Filter to convert to CRLF EOLs."""
> -    if util.binary(s) or inconsistenteol(s):
> +    if util.binary(s):
>          return s

Are we sure it's a good idea to normalize inconsistent files like this?
I'm inclined to say yes -- when the eol extension is in effect, it takes
care of all newlines. So I would be okay with the extension always
enforcing the newlines.

I spotted this because it changes the output from the test-suite. The
changed output look like this (four times):

 % hg commit of inconsistent .txt file marked as binary (should work)
 % hg commit of inconsistnet .txt file marked as native (should fail)
-abort: inconsistent newline style in a.txt
-

I'm running the test suite by doing:

  cd ~/src/hg-eol/tests
  ~/src/mercurial-crew/tests/run-tests.py -l

that is, I execute the run-tests.py file from my local Mercurial
installation.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/