[MERGE] do not export .bzrrules

[Ian Clatworthy]

Martin Pool wrote:
> On Fri, Jul 25, 2008 at 11:16 AM, Ian Clatworthy
> <ian.clatworthy at canonical.com> wrote:
>> Currently, the export command skips over .bzrignore. This
>> simple patch extends that logic so that other "magic"
>> files in the .bzr* namespace - like .bzrrules - are
>> skipped over during export as well.
> 
> I'm not so sure we should be skipping all of these files from export
> by default.  An option to exclude them could obviously be useful.
> 

Robert has requested that the code be explicit and only mask out
.bzrignore and .bzrrules. It sounds like you agree? If so, I'll
change it. But ...

It's fair to say they we know we aren't going to get agreement
on the topic of whether these files ought to live in the tree
or not. I kind of feel we've discussed this topic to death :-(
with at least 3 options debated since April:

1. Taking them out of the tree is the cleanest solution but
   it's an expensive one because we don't have a separate
   architecture for managing user-editable out-of-tree files.
   I'm not planning to write one. I don't see it as a
   priority for others either: this never makes the top 10
   reasons - to my knowledge - as to why users are choosing
   other tools.

2. The cheapest solution is reserving the top level .bzr*
   namespace for these. It isn't perfect but almost every
   other tool does it that way so we're no worse than the
   competition.

3. I suggested one reserved directory (.bzrconfig IIRC) as
   a step towards 1. We decided against it for numerous reasons,
   one of which was that we may want to support .bzrignore and
   .bzrrules per directory (ala git) one day and that feature
   would be more easily understood as a evolution of 2.

So my leaning is that we ought to be *generalising* the code here,
not needing to come back to it each and every time a core feature
or plugin has data like this to manage. I feel masking out the
.bzr* namespace is the correct implementation of policy 2.
If that is overkill, I'd suggest a registry of patterns to mask
out so plugins can add to it without needing a change (again)
to the code. If even, the beauty of masking everything in the
special namespace is that it's easy to explain and won't change
what's in or out of an export from release to release.

BTW, I do have another patch up - get_special_file - that
suggests an API for accessing files in the special .bzr*
namespace. As well as solving other bugs (like the infinite
recursion one that I'm seeing), having and using an abstract
API like that will ease migration to a better way later.

Ian C.