[PATCH] Implement --strict flag for commit

[James Blackwell]

> On Mon, 2005-10-17 at 20:07 -0400, Aaron Bentley wrote:
> > I worry that this would lead to unnecessary acrimony, because it would
> > be a way for people to control other peoples' settings.  Consider the
> > arguments over modelines in the baz source.  I also find it quite
> > confusing when rules apply only in certain branches.  So I would prefer
> > a global option.
  
On Tue, Oct 18, 2005 at 11:55:38AM +0200, David Allouche wrote:
> Agreed on that point. Policy should be defined per-user, not per-branch.

I actually disagree. A downward-only propogating ini file (done by copy
ini file on branch, but don't include in merge/diff) would be a great
thing for users. This allows a branch to set sane defaults to get branched
from which can easily be overriden. 

I think this for several reasons. I anticipate gobs of potentially useful
meta-info that goes along with a branch that one wouldn't want 2,000 users
having to set. Imagine these: 

 * a bts line in the ini file for a branch that reports to the bts that a
   bugfix is ready for merging :
      bzr fixed 3983 "Added { and } for flow control in python"

 * a pre-commit hook that automatically lints and possibly runs tests upon commit.

 * an upstream file that provides a list of sites that the branch is
   stored at (i.e. multiple mirrors).

 * a branch hook that says "Oh! A config. Lets get the rest of these too"

The flip side of this would be to tell users "first branch me, then copy
this information into your local ini file...."


On Tue, Oct 18, 2005 at 11:55:38AM +0200, David Allouche wrote:
> Here's a little thought experiment to make the point. Say you have two
> value for a policy: "strict" and "loose", where anything valid in
> "strict" is also valid is "loose", but not conversely. Also say you have
> a branch maintainer and separate branch contributors who may have
> different preferences for this policy, with reasons ranging from
> personal taste to tool-chain support.
> 
> Cases A and B are conflictual if the settings are defined in the branch,
> as any setting will make somebody unhappy, and merging will cause
> trouble.

This is worked around by having a branch in the middle: 

[Official]--->[dev-a]|---> [fix1]
         |           \---> [fix2]
         |
         |--->[dev-b]|----> [fix1]
	             |----> [fix2]
		     |----> [fix3]

This works great from a caching standpoint as well. Branch from official
into dev-a, make your preference changes, then branch from that whenever
you want a new branch. 

>       * Policy enforcement in the tool-chain must have defaults set by
>         the user, not by the Maintainer.

I just can't bring myself to buy this argument. Look at the value-add of
distributions -- not only do they provide you the code, but they generally
provide a reasonably sane startup-config that one is welcome to override
by making local changes.  These minimal configs make it much easier for
users to get going -- The lets-get-going is already done, and one can push
the installed code in the direction that's actually called for.


> 
>       * The tool-chain should support diagnostic tools exercising the
>         strict policy, so automated quality insurance (e.g. test suite)
>         can easily spot violations at the time most convenient to the
>         user.
> -- 
>                                                             -- ddaa