[MERGE] Rule-based preferences (EOL part 1 of 3)

[Ian Clatworthy]

Martin Pool wrote:
> On Fri, May 16, 2008 at 6:02 PM, Ian Clatworthy
> <ian.clatworthy at internode.on.net> wrote:

> More importantly - this seems like the first mention of having rules
> inside the branch/ directory (unless I just missed a previous thread?)
> and since it's quite substantial you should call it out more in your
> review.

Well, I was trying really hard *not* to add that complexity and to only
have per-user rules. The trouble was that every example I came up when
writing the README.txt files for the relevant plugins cried out for it,
i.e. having the ability to control eol behaviour only at the global
level felt lame and somewhat unsafe.

Yet, as best I can tell, Hg's eol support is at that level, so maybe
I'm missing something. Can those more familar with Mercurial's win32
extension express an opinion?

> I don't think putting a rules file in there is a good idea; in general
> everything in there should be determined solely by the branch format.
> Adding a new one would require a branch format bump, and also code to
> move them around, merge them, diff them, etc.  I think it would be
> much more appropriate to put it in the working tree as .bzrrules.
> (I'm happy to explain more about why this is so either in mail or
> elsewhere if you want but won't flog it for now.)

So we're back to this dilemma we seem to run into over and over again,
namely that opinions within the Bazaar community for managing stuff like
this span the complete spectrum, so despite the wonders of Python,
some things take a long time - vs competitive projects - to get through.

Personally, I'd be happy putting a .bzrrules file in the tree because
we have a file management architecture (status + diff + merge + commit
+ update/pull/push + ...) for files in that location. But, as you know,
Robert (and others) will reject that because it locks us into a "format"
which is more difficult to upgrade. I don't agree it's as big an issue
as others, but I also don't have their experience and we all need to
support this.

I could leave out the branch.rules support from the initial version and
only support bazaar.rules. My concern is that the end user result (e.g.
configuring the eol plugin with the same preferences across all
branches) would be unsatisfactory. So I *want* branch-specific
configuration and I'd like to argue that we can have that without
needing a new branch format or a new outside-of-tree file management
architecture.

I'd like to question some of your points above:

1. Is it really true that everything under .bzr is determined by
   the repo/branch/tree "formats"? Is it illegal for plugins to
   add files there and if so, where should they put them? It really
   frustrates me that we have a beautiful open code architecture
   (plugins) yet our data architecture is so closed, requiring
   multiple upgrades per year for many users. I struggle to see,
   and to explain to Joe Average users, why adding some optional
   preferences to a branch is worthy of a branch upgrade, at least
   until such time as those things are versioned.

2. We don't move and merge everything under .bzr now do we?
   branch.conf?

One of the reasons why I called these settings "rule-based preferences"
is because they don't have to be set and different users may *want*
different values. I actually think the similarity between our
*.conf files (bazaar.conf, locations.conf, branch.conf) and the proposed
*.rules files (bazaar.rules, branch.rules) is strong. I also feel that
projects have other ways of getting the right preferences in place
(e.g. documentation, plugins) so we don't *need* commit+merge for
these things in the very first cut.

So let me ask the question this way: why is making .bzr/branch/branch.rules
an optional file in existing branch formats the wrong thing to do?
Of the 1000s of users out there, who would be harmed by that and what
is the practical likelihood of that happening?

Apologies if the above sounds too defensive. I'm just very concerned
that this is going to end up as "write an out-of-tree file management
system and move .bzrignore to it before landing this". I feel that
would put idealism ahead of our users: the idealists are *already*
using Bazaar while others would *like* to but are going with other
tools because we're missing stuff that matters more (like EOL support).

Ian C.