Eol conversion affects bzr st

[Kirill Suzev]

Using bzr 2.2.1 on Win7 64-bit
I wrote to rules file the following:

[name *]
eol = crlf

After that I ran a command:
bzr co https://launchpad.net/bzr/trunk/ <folder name>

Bazaar checked out successfully. After that I ran command:
bzr st
modified:
  bzrlib/util/effbot/__init__.py
  bzrlib/util/effbot/org/__init__.py
  bzrlib/util/effbot/org/gzip_consumer.py
  bzrlib/util/effbot/org/http_client.py
  bzrlib/util/effbot/org/http_manager.py
  doc/ja/tutorials/centralized_workflow.txt
  tools/win32/build_release.py
  tools/win32/start_bzr.bat

Between checkout and bzr st I didn't change the content of files, so that was a surprise.
I checked dirstate for start_bzr.bat:
689 n <email address hidden> tools/win32 start_bzr.bat start_bzr.bat-20060622100836-b3yup582rt3y0nvm-9 f 55a80944034f8b260d0d923a5f2906e4538a7b26 917 n AAADlUzYGDBM2BgxAAAAAAAAAAAAAIG2 f c8c3beffe1ab8c458c6b45e944fb3cec0f5176e2

So, looks like the sha differs.
But if I leave rules file empty, and then checkout bzr again, bzr st will report that everything is ok.

[Kirill Suzev (suzev-kirill)]

Hello?

[Kirill Suzev (suzev-kirill)]

Guys, I would really appreciate your help here.
I investigate a little bit and found, that if I specify eol type in rules file, bzr thinks, that all files in remote repo have common eol type (lf in my case). Which is not true for this case.
So? Any movements?

[Frits Jalvingh (fjalvingh)]

Hi Kirill,

This problem is very common and also described in bug# 395731. To understand what happens you need to understand how content filtering works.
You had an existing repository created with Windows clients and without filtering rules. This means that all files are committed "as is", with CRLF line endings as is common for Windows.

Now you add the rules file and thereby enable content filtering. When you do that Bazaar will "filter" your local data. For line endings this means that Bazaar will store a "canonical" format line ending in the repository, and it will "translate" this canonical ending to CRFL when data moves out of the repository, and it will translate line endings back to canonical format when data moves into the repository (= from your working tree). The "canonical" format for line endings (in your rules spec) is LF..... And this is the cause of your problem.

By setting this rule file, bazaar will first "filter" all of your local content and convert all CRLF to LF. After that it will calculate the content hash- and that differs from the repository's hash because the content actually changed! The repo contains CRLF while the filtered content now uses LF.

This is the reason why all text files appear to have changed...

This is actually a huge "bug" in my opinion, because commiting this will cause a commit where all files actually change fully. It means that any merge from before that point will fail with a huge conflict.
In addition, any client that does not have the proper rules file /locally installed/ will cause this same problem, destroying the repository.

I hope this makes the problem more clear. I am trying to get the devs to fix this; a proposal is being made on

http://wiki.bazaar.canonical.com/fjalvingh