[MERGE] branch.has_explicit_nick

[Aaron Bentley]

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

Robert Collins wrote:
> On Fri, 2006-06-30 at 10:58 -0400, Aaron Bentley wrote:

>>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 remember that there was a lot of contention about what should be
stored where, and so we concluded that we should allow anything to be
stored anywhere.

But I also thought that your opinions in these matters had shifted some.
That you were now willing to think of cp and 'clone' as a distinct
operation from 'branch', and felt that it was okay for 'clone' to copy
all settings.

The attributes that are interesting to me are

locations.conf
- - trusted
- - can always be written to

branch.conf
- - publically viewable

> I'm a little concerned that -too- much flex in the configuration system
> forces users to understand that entire grid.

I understand that concern, but

> Some options should only be
> in some places, because that makes the system simpler - not to mention
> more secure.

Unfortunately, we can't agree on which options should go where, and
pretty much any option that can go in branch.conf should also be
available from locations.conf, because branch.conf may not be writeable.

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

I think that most options are ideally kept in branch.conf, so that they
are publically available, but that all branch options must be
configurable in locations.conf because branch.conf may not be writeable.

So I think making a special case of 'nick' would be bad, even though it
is almost never used in readonly operations.  Then only example I can
think of is bzr viz, which puts the branch nick in its title bar.

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

I agree that with your hunch that few people will want to vary policy
separately from branch type.  The only exception I can see is if people
want to make the .bzr/branch.conf of local branches a trusted file, and
that could be done as part of the config.

The reason for separating out the classes is for separation of concerns,
not to allow them to vary independently.  You already had a BranchConfig
that knew about some policy, e.g. the email stuff.  I decided to move
the fallback from location to global config in there also.  I think
there's enough meat here that it's nicer to take it out into a separate
object, rather than do it in Branch.

> 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 don't like the former, because it would then be hard to get at the
branch.conf data without fallback.  The latter would be okay with me.

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

Well, I'm not 100% sold on the idea, but I certainly wouldn't veto it.
Just that I'd rather keep config policy in BranchConfig.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEpWYV0F+nu1YWqI0RAsh2AJ4nPGJo3RU3W3ppWeiA7Fi55HmPcQCgiF9P
1KzV9y3CHM9FZK5VewSuOCI=
=MNjm
-----END PGP SIGNATURE-----