[MERGE] do not export .bzrrules

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
| 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.
|
|

Just to mention, if you make this ignore list a set/list that plugins
can access, they can insert their own entries into it.

We already allow run-time inserts into the global ignore list (bzr-shelf
does this so people don't accidentally version their .shelf directory).
It would just be a run-time "ignored for export" list.

I probably favor (2) and ignoring everything starting with .bzr* during
export. I *do* wish we had a better answer, but ATM we don't.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiQf/0ACgkQJdeBCYSNAAPxZQCfVSEwTO0H/qSOU3isMmU3lnRd
mXsAoNgr6LpXFIV/zBwIQcXXuzoc/mJ1
=H8f+
-----END PGP SIGNATURE-----