Breezy

Eol conversion affects bzr st

Bug #672612 reported by Kirill Suzev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
High
Unassigned
Breezy
Triaged
High
Unassigned

Bug Description

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.

Tags: eol filters
Revision history for this message
Kirill Suzev (suzev-kirill) wrote :

Hello?

Kirill Suzev (suzev-kirill)
summary: - Eol conversion affects diff
+ Eol conversion affects bzr st
Revision history for this message
Kirill Suzev (suzev-kirill) wrote :

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?

Revision history for this message
Frits Jalvingh (fjalvingh) wrote :

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

Vincent Ladeuil (vila)
Changed in bzr:
status: New → Confirmed
importance: Undecided → High
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: added: filters
removed: check-for-breezy
Changed in brz:
status: New → Triaged
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.