[RFC] .bzrconfig directory

Ian Clatworthy ian.clatworthy at internode.on.net
Thu May 22 05:45:56 BST 2008


Aaron Bentley wrote:
> Ian Clatworthy wrote:

>> 1. rules
>> 2. ignores
>> 3. (shell) hooks
> 
> Would that be a possible attack vector for malicious users?

I assume you're referring to just the (shell) hooks line?
I guess so. Perhaps the hooks themselves can be managed like this
but each one would need to be explicitly enabled in a (per user)
config file say? FWIW, I don't necessarily want to solve this issue
in this thread though. My larger point was more about "there's more
we probably want to shove in here than just ignores and rules".

>> 4. branch.conf (not totally sure about this one)
> 
> Well, I've been feeling uneasy about branch.conf's specialness for a
> while.  This wouldn't entirely fix it, because the other files you named
> would be versioned files, and branch.conf must not be versioned.  But
> it's worth considering.
> 
> Also worth mentioning is that my stacking policy work introduces another
> source of configuration; a file named something like .bzr/config.conf
> 
> Right now, it only controls stacking policy, but it could potentially
> also control whether working trees are created when branches are created
> under this directory (the --no-trees flag to init-repo).

So going back to original "dimensions", we have:

1. editable by user (.bzr=no; .bzrconfig=yes)
2. versioned and propagated (.bzr=managed-by-bzr; .bzrconfig=yes)

branch.conf really is an odd fish: it's editable by the user, not
versioned and not propagated.

>> Plugins may want to put things in here as well.
> 
> Right.  Shelf being one example.

Hmm. I can imagine the dimensions above are also less than optimal
for plugins. What if a plugin doesn't want certain data versioned and
propagated? It could tell the user in the README to add certain lines to
their ignores but that seems flaky. Maybe we'd be better to have a fixed
location under .bzrconfig which was ignored by default, e.g.
.bzrconfig/local, .bzrconfig/private or something like that. Perhaps
branch.conf could live in there?

> If we have a .bzrconfig directory, I would want it to exist whether or
> not a working tree is present, even though it would be a versioned file
> if the working tree was present.  Implementing that could get kinda ugly.

Can you explain further? I agree that a shared-repo or treeless-branch
*might* have this file - it wouldn't only apply to working trees. Not sure
I grok all the implications of that though.

Thanks for the feedback btw - I was really hoping you'd chime in on this
topic soon. :-)

Ian C.



More information about the bazaar mailing list