Working tree content filtering & a proposed plan for eol support

[Ian Clatworthy]

Alexander Belchenko wrote:

> I don't read your email in details yet, so I just attach to this mail
> simple diff with my only eol-related changes. You can use it freely.
> This diff created against bzr.dev revno.3293.

I've spent a fair amount of today looking over and working on this. Your
code has been *very* helpful - thanks. Here's my current thoughts/plan ...

I'm planning to put up a branch/patch that supports a stack of working
tree content filters. Eol-handling will be an instance of a content
filter. Other content filters can be plugged in later to do other fancy
things like:

* keyword expansion
* tab <-> space conversion
* whatever.

FWIW, I wasn't is the "EOL Support" working session in London but I
*think* that's consistent with the approach Aaron and Robert agreed on.

In the first patch, the code deciding which filters to apply to which
paths will return an empty stack. A second patch will provide that
mapping logic, probably by tapping into our configuration system in a
manner much like Martin has suggested in another email. (BTW, to ensure
this feature is only enabled for early adopters, the stack of content
filters will always be empty unless some magic config setting is
explicitly enabled.)

The third piece of the puzzle is writing the various eol content
filters. I think this will largely be a refactoring of Alexander's
bzrlib/prop/eol.py into bzrlib/filters/eol.py.

After that, we'll have something useful as a prototype. Before calling
it production code, I'll look at the cost/benefit of adding a new
workingtree format. After talking to Robert on the phone yesterday, I
now appreciate that there are a range of nasty bugs that can be avoided
by only permitting smart content filtering on trees that understand
them. Please note that new workingtree formats are far less intrusive
than new branch or repo formats *but* they still carry some upgrade
overhead and I don't want to make the "too many formats" issue a bigger
one. As a side note, Martin has suggested that the upgrade part of our
UI could do with some streamlining.

If and when a content-filter-aware workingtree format lands, we can drop
the need for the magic config setting and make this (awesome) feature
available to the masses. Otherwise we document the magic config setting
and warn people loudly in the User Guide about the potential mess they
can make (e.g. accidentally committing the full content of all text
files multiple times, screwing up merges, etc.) if they aren't careful.

I hope this plan provides a way forward. Does it sound OK to everyone?

Ian C.