[PATCH] configuration policies

[James Henstridge]

On 26/11/06, Wouter van Heyst <larstiq at larstiq.dyndns.org> wrote:
> On Fri, Nov 10, 2006 at 04:03:35PM -0600, John Arbash Meinel wrote:
> > James Henstridge wrote:
> > > On 07/11/06, James Henstridge <james at jamesh.id.au> wrote:
> > >> The attached bundle implements configuration polcies.  The main new
> > >> features are:
> > >>
> > >> * support the equivalent of recurse=False for a subset of options in a
> > >> section
> > >> * have an "append path" policy allowing for e.g. a single
> > >> push_location setting for an entire tree of branches.
> > >>
> > >> The branch maintains support for recurse=False option in sections, but
> > >> will convert it to a "policy_norecurse" key if bzr writes to the
> > >> section.
> > >
> > > Attached is an updated version of the patch, based on feedback from
> > > Aaron and John on IRC.  It now uses one key per option to specify
> > > policy rather than one key per policy.
> > >
> > > As an example of use of the plugin, consider the case of someone using
> > > bzr to work on a project that uses PQM.  They maintain a local copy of
> > > the branches, with a mirror at a public location.  There are multiple
> > > products they can submit merges to, and they organise branches for
> > > each product under different subdirectories.  This patch would allow
> > > the following minimal setup:
> > >
> > >    [/path/to/repo]
> > >    pqm_email = pqm at example.com
> > >    push_location = bzr+ssh://publichost/~/public_html/repo
> > >    push_location:policy = appendpath
> > >    public_branch = http://publichost/~user/repo
> > >    public_branch:policy = appendpath
> > >
> > >    [/path/to/repo/product1]
> > >    pqm_branch = http://example.com/product1
> > >    [/path/to/repo/product2]
> > >    pqm_branch = http://example.com/product2
> > >
> > > This will make "bzr push" do the right thing for any local branches
> > > under /path/to/repo, and "bzr pqm-submit" will also work, picking the
> > > PQM target branch based on the subdirectory where the branch is
> > > stored.
> > >
> > > James.
> > >
> >
> > I like the syntax. Though I'm curious about
> >
> > 1) Is it compatible? (As in with current settings will users experience
> > weird differences if they aren't aware of this switch).
> > It seems like it is compatible, as you have to explicitly set :policy =XX
> >
> > 2) If you do 'bzr push' does it end up creating a new entry? I'm
> > guessing it doesn't since the code is generally:
> > saved_loc = config.get_push_location()
> >
> > if saved_loc is None:
> >
> > or
> >
> > if config.get_push_location() is None:
> >
> >
> > If that isn't the case, we may need to think about it. Because it means
> > the policy starts breaking for nested entries. But I *think* it will
> > just work correctly.
>
> Has anyone tried using this? If there are no quirky corners I think this
> change would be very good to have.

I've used it locally, and it seems to work okay :)

It would be quite useful for Launchpad development since it means we
generally work with short lived feature branches and it would allow
developers to configure their "bzr push" and PQM submit locations once
and have it work for all their branches.

As far as nested trees go, this patch does change the behaviour a bit,
but I consider the previous behaviour broken.  Consider the following
case:

1. user creates a branch as /a
2. user creates a nested branch as /a/b
3. user runs "bzr push http://myserver/a" when in /a

This causes a push location to be remembered for /a.  With current
Bazaar, the remembered push location will also affect /a/b, so that
"bzr push" in that branch will also push to http://myserver/a (not
http://myserver/a/b).  This is almost certainly not desired behaviour,
since we have two different branches pushing to the same location.

With my patch, the remembered push location for /a has the norecurse
policy, so does not affect /a/b.  This seemed to be the most
conservative choice at this point.

James.