© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
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://