[RFC] .bzrconfig directory

[Ian Clatworthy]

Martin Pool wrote:
> On Tue, May 20, 2008 at 11:01 PM, Aaron Bentley <aaron at aaronbentley.com> wrote:
>> Stefan Monnier wrote:
>>> I'm probably sounding like a broken record, but in any case I'll restate
>>> that I think the Arch way was right:
>>> - treat it like a normal user file (w.r.t merging, changing,
>>>   committing, ...).
>>> - but place it somewhere inside the .bzr directory.
> 
> So we have at least five categories of possible file, the first four
> of which we use at present:
> 
>  0- internal files: inside .bzr; users should never touch it;
> rewritten by upgrades; propagated according to semantic rules; read
> and updated only by abstract apis and commands, not directly
> 
>  1- source files: regular user data; not in .bzr; we never rewrite it
> and it's merged as a text file with no special interpretation
> 
>  2- .bzrfoo files: the only example at present is .bzrignore; just
> like source files but they affect bzr too
> 
>  3- eg branch.conf: users may edit it and stored verbatim; not
> propagated at all; read by bzr (but this is a bit of a strange fish)
> 
>  4- what Stefan proposes: just like a .bzrfoo file but stored inside .bzr
> 
> The main advantage of the last seems to be: less clutter in the source tree.

It would be nice if we could get this to 3 (and only 3?) categories:

1. internal files (inside .bzr) - owned by Bazaar and not to be edited

2. special files (inside .bzrconfig say) - read by Bazaar but generally
   added/edited/managed by the user and propagated like normal files

3. user files (everything else) - regular user files

So I'm proposing we consider a new optional directory into which we
begin putting/migrating special files. Here are some of the things I'd
expect to see in there in the fullness of time:

1. rules
2. ignores
3. (shell) hooks
4. branch.conf (not totally sure about this one)

Plugins may want to put things in here as well.

I think explicitly supporting one special directory like this has
numerous advantages:

1. It keeps the tree clean and the semantics of each area clearer.

2. It's more extensible over time than adding more .bzryyyy files
   because some special files will benefit from being organised
   into directories, e.g. hooks, plugin data.

3. It allows the core code to be generalised, e.g. the export
   command shouldn't output that directory (just like it explicitly
   masks out .bzrignore now).

4. The core code may need/want to prioritize how the special files
   are handed, e.g. read/transfer them before others, use different
   merging algorithms (as Alexander was doing in his original eol
   patch). As these files may affect how bzr or plugins behave,
   maybe users need to resolve any conflicts here before we even
   attempt to merge the other files? (Maybe not needed in the first
   cut but feels like a sensible direction to be heading.)

I see two main questions:

1. Why make it a separate directory vs another directory in .bzr?

2. The name.

I think a separate directory is better because it can have its own
namespace - one that makes sense to users - without being cluttered by
the current .bzr files. E.g. a .bzrconfig directory might look like:

  .bzrconfig/
    hooks/
      branch/
        pre_commit.d/
          ..
        post_change_branch_tip.d/
          ..
    ignores
    plugins/
      shelf
    rules

I'm not passionate about the .bzrconfig name. I'd also be fine with
.bzrpublic or several other names. (I actually like .bazaar the most
but we can't use that without clashing when users want to manage
their home directories on Linux/Unix.)

Thoughts?

Ian C.