[MERGE] branch.has_explicit_nick

[Robert Collins]

On Fri, 2006-06-30 at 10:58 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> 
> >>My initial reaction is that I want my explicit nicks to behave the same
> >>as my implicit nicks.  Could you say more?
> > 
> > 
> > Well they clearly dont: rename a dir with an explicit nickname, and the
> > nick does not change.
> 
> If you set the explicit nick in locations.conf, it will :-P

Meep. I think we're into very confusing territory here. Do you remember
the diagram I put on the whiteboard in montreal - the combinations of
'where we can store things' , and 'should things be preserved by rename'
and 'should things be preserved by copy' and 'should things be preserved
by branching'.

I'm a little concerned that -too- much flex in the configuration system
forces users to understand that entire grid. Some options should only be
in some places, because that makes the system simpler - not to mention
more secure. 

Specifically, I dont think nickname is useful to set in locations.conf -
unless I'm missing something.

> >>The recent puts BranchConfig in charge of policy for determining config
> >>options.  For example, BranchConfig knows that it should try to read
> >>.bzr/branch/email to determine the per-branch email address.  And it
> >>also knows that 'post_commit' should never be determined from a TreeConfig.
> > 
> > 
> > Sure, I think my later patch took this into consideration. 
> 
> The second one (which I was replying to) took it into more
> consideration, but it took some of the policy knowledge (i.e. where to
> get a nick if there's no explicit nick) out of BranchConfig, and put it
> in Branch.

This would be good IMO if different branch types will want to vary their
policy separately from the branch type. my hunch is that this is not the
case, and folk subclassing Branch will end up always subclassing
BranchConfig to, unless their policy is the default when they wont.

Anyhow, I dont have a very strong opinion here, because better
decoupling is usually good, so I'm not arguing that everything should be
on branch.

> > FWIW I find
> > having both TreeConfig and Branch config confusing, and TreeConfig is
> > for Branches and BranchConfig is for branches.
> 
> I agree, and I'd be happy to rename them.  Here's how I see the
> relationship of our various config classes:
> 
> Policy-based-configuration object: BranchConfig
>   Maintins no (or very little) data on its own, but gets and sets data
>   in other, more specific objects.
> 
> Branch contents-based configuration object: TreeConfig
>   Ini-based config that gets and sets data in the branch directory,
>   itself.
> 
> Location-associated configuation object: LocationConfig
>   Ini-based config that gets and sets data in local configuration files.
>   Can also store data for locations that are not branches.
> 
> Global configuration object: GlobalConfig
>   Ini-based config that gets and sets data in local configuration files.
>   Not associated with any particular branches.


TreeConfig IMO should be called BranchConfig, and probably BranchConfig
and TreeConfig should be the same class. Either that, or
BranchConfig->BranchConfigPolicy and TreConfig->BranchConfig.

I'd like one of these to occur before 0.9, so we dont have an API
collision to deal with.


anyhoo, we're way off the track which is 'can I get this ability to test
for a nickname being set as a public api please'.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060701/ca7f97ee/attachment.pgp