EOL filter problem summary.

[Adrian Wilkins]

After a rather rude Windows application (SharpDevelop) flipped the 
line-endings on some of my source, I began to check out the EOL 
filtering feature.

Some of these things have bugs, I know, and at least one of them is 
fixed, and others may be side-effects.

Problem #1

Only files you check out are EOL filtered, not files that subsequently 
arrive in updates.

This is now
https://bugs.launchpad.net/bzr/+bug/385879

I've just verified it - files that you rm and then revert using bzr.dev 
are not filtered.

Problem #2

Files are reported as changed after they are EOL filtered to another 
line ending.

This is known and fixed and is
https://bugs.launchpad.net/bzr/+bug/362030


Other questions...

#3  What happens to files that are already present with CRLF endings 
that subsequently match a rule after it is applied?

e.g.

My CSharp library was initially created on Windows in SharpDevelop (with 
CRLF endings and no EOL filter on). I pushed the branch to Linux, where 
the MonoDevelop respects line endings and preserves them. I create 
several more source files with LF endings and commit them. I push back 
to Windows later.

Windows updates the branch with the new files. They still have LF 
endings (no content filter on yet though).

After editing in SharpDevelop, the files are one long diff - it's 
flipped the line endings. I curse quietly and research eol filtering for 
the first time. After being rather frustrated and finally resorting to 
reading the source code and also profiling the file system usage of bzr, 
I set my rules file to read

[name *.cs]
eol = native

Which should cover all those CSharp files. I then go back to my folder, 
touch all my *.cs files.

  - Files converted to CRLF endings are still noted as changed (#362030)
  - Unedited files which have LF endings are unchanged (but should be - 
and reverting them should make them CRLF ended) (also the same bug)
  - Files which were originally CRLF ended are still that way, and 
reported as unchanged.

I add some more files and commit them to the Linux side, then pull these 
to Windows. They retain their LF endings, even though filtering is now 
on (#385879)

So, crossing the EOL filter line

CRLF files committed on Windows with no filter are stored as CRLF. On 
Linux, such files retain their CRLF ending in the tree and are 
considered unchanged (both in 1.15 and bzr.dev with the fix for #362030) 
even if matched by a rule. They continue to retain CRLF endings even 
after commit, removal, and revert. Which is probably what you'd expect ; 
but I'd like to see them checkout out as LF (even though it doesn't 
affect my use case because MonoDevelop copes gracefully with CRLF endings).

If you flip an LF file to CRLF on windows, bzr.dev now correctly ignores 
the change, but it also considers the original LF file to be unchanged, 
which I suppose is correct behavior in the absence of filtering, but is 
it so with the filter on? Should it regard LF files that should have 
been filtered to CRLF as changed?

When you checkout a 1.14 branch you get a 1.9 tree (because the branch 
format hasn't changed). Perhaps an optional extra item in the branch to 
suggest which tree format to use would be useful - older clients could 
safely ignore it.

Per-tree rules really need to get finished too, although I can see them 
causing run-ins with some of these issues in here, because the rules 
will be able to change on a per-revision basis.