RFC: advisory "branch_status" flag in branch.conf

[vila]

>>>>> Jelmer Vernooij <jelmer at samba.org> writes:

<snip/>

    > Adding some hierarchy to the configuration options makes sense, but I
    > wonder if the plugin that happens to be using a particular option is
    > really relevant. For example, what about options that are used by
    > multiple plugins?

Well, some synchronization is needed in this case and without a concrete
example, I'll tend to say that if multiple plugins needs the same
option, there is a strong incentive to support it in bzr itself.

    > I'm not necessarily disagreeing with you that it would be useful
    > to prefix the option with "colo.", but I think it should have that
    > prefix because it applies only to colocated branches, not because
    > it happens to be used by the bzr-colo plugin.

Sure.

The rules I propose are about avoiding accidental collisions, this
doesn't forbid sharing.

The discussion went like:

- eeerk, we will have collisions and we need a simple way to give names
  to config options,

- let's use the already existing python name space, if you declare a
  'status' config option in bzrlib.branch, let's call it
  'bzrlib.branch.status',

- omg, plugin authors and users will hate us ! Think about
  'bzrlib.plugin.bookmarks.my_shortcut' !

- hmm, right, instead, let's do s/bzrlib/bzr/ and
  s/bzrlib.plugin.<plugin>/<plugin>/

But really, there is no strong reason to tie the option name to a python
module (other than reusing the logical names), so in the end it's just
'bzr.' for bzrlib and '<plugin>.' for plugin specifics.

Since Neil explicitly started an RFC, I hi-jacked the thread a bit but
my point was mainly to use 'bzr.branch.status' or 'colo.branch.status'
rather than the raw 'branch_status'.

I agree with Martin that it's fine to leave it unset ;)

  Vincent