[RFC] .bzrconfig directory

[Martin Pool]

On Thu, May 22, 2008 at 11:41 AM, Ian Clatworthy
<ian.clatworthy at internode.on.net> wrote:
> Martin Pool wrote:
> 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 if these files are propagated in the usual way that has a couple of
consequences.  One is that you can't use it for local setting related to
this branch which should not be merged, which is what branch.conf does at
the moment.  We could perhaps afford to lose that and do something similar
in locations.conf?  The more difficult one is that you're trusting data
merged from someone else; if this controls things like hooks it is
problematic.

> 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)

If hooks and branch.conf aren't in this catergory then it's a bit small...

> 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).

I think that should only be an option on export; anyhow masking a
.bzrconf directory is no harder than masking .bzr*.

> 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.)

Again, that could be done just by filename.

I don't have a strong opinion about a subdirectory but I'm not convinced
we need it.

Could we fit more of these settings into just a few configuration files?

-- 
Martin <http://launchpad.net/~mbp/>