Status update & proposed direction for branch-specific rules

[Ian Clatworthy]

The key feature still missing from Bazaar in order to make end-of-line
conversion and keywords fully supported is branch specific rules. Right
now, rules can be defined only at the global "per-user" level: in
.bazaar/rules on Linux/UNIX and the equivalent location on Windows.

This feature has had a sad past. After spending many weeks discussing
various options back in May 2008, it was implemented via a .bzrrules
file during early versions of 1.6. But the core team couldn't agree:
Martin, John, Alexander and I supported it while Robert and Jelmer
didn't. From memory, Aaron abstained but I suspect he agreed with Robert
in principle. In the end, Robert asked in August for .bzrrules to be
unversioned and Martin decided to go further and drop it altogether.
With no immediate need for the feature then (content filtering hadn't
landed) and with me fighting a personal health battle that meant I
wasn't going to be around much for the rest of 2008, I reluctantly
agreed to drop it (rather than leave a feature for others to support
that they didn't agree with).

More recently, I put forward a proposal for using a configuration
setting pointing to an arbitrary URL holding the rules to use. See
http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/51347.
This had more luck on the agreement front but my proof-of-concept hit
some hurdles. Alexander took over the branch and ran into additional
issues. Basically, it just isn't going to work as well as I originally
hoped because we need the file to build the working tree and it
therefore can't be an option for it to exist in the working tree. In
turn, that means that it can't be versioned with the rest of the code,
optionally or otherwise. The final outcome would have been below our
"Just Works" usability standard as well. I want Windows users to be able
to simply "bzr branch URL" and get the right line endings. Having to
setup a file and configure a setting before branching just isn't good
enough. That would fall into the "incremental feature addition which
isn't clean" camp that Mark has asked us to explicitly address for 3.0.

So there are at least 3 options going forward:

1. Restore support for .bzrrules. This is simple to do but doesn't solve
   the long term concerns raised previously.

2. Fight though the issues implied by the RULES_LOCATION approach.
   The hoped-for advantages of this solution (simple, flexible) weren't
   real and it doesn't solve the long term problem either.

3. Design and implement an out-of-tree-but-versioned solution for
   rules, ignores and anything else that needs it. This may take a long
   time to do, but then again it may not, depending on how it hangs
   together.

I'm going to have a crack at #3 and if that doesn't fly, argue for #1.
I've had some thoughts over the weekend that I've written those up as a
draft spec. See http://bazaar-vcs.org/DraftSpecs/MetafileManagement.

Thoughts?

Ian C.