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

[Robert Collins]

On Tue, 2008-05-20 at 01:06 +1000, Ian Clatworthy wrote:
> 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.

I think one reason to be careful with a new file in .bzr/branch is that
we have so far *largely* kept from having user editable files in control
directories; if the expectation is that there is a bzr UI for managing
these files that would be nice.

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

the .hgrc can be in .hg/ or in the users homedir, or possibly other
places.

> > 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 won't reject it; I think it would be a mistake so I certainly wouldn't
approve it, but perhaps we simply have to learn this lesson again, if
Aaron and I are failing to express the issues satisfactorily. 

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

Plugins that need user settings can use the get_user_option api to get
settings (side-note: why doesn't that suffice?). Yes it is illegal to
put files there - consider 'bzr-svn' which provides branch and tree and
repository objects - there is no .bzr directory for them, and its having
a clear abstraction barrier there that allows it to work as seamlessly
as it does. Typed data for the win. There isn't even a guarantee that a
branch at a url actually *has* a directory attached to it - it can just
as reasonably be a postgresql database or some other system. Making it
expose a read-write file system is not very clean.

As for adding a file to an existing format, you're right. There is no
argument against doing it that cannot be counter argued. But every time
we do, we have fallout, which in the past has ranged from bzr failing to
behave correctly through to bzr performance suffering.

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

Indeed, we don't. We either copy (.clone()), derive (.sprout()), or use
explicit apis (tag merging, pulling etc).

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

This is pretty rhetorical. Clearly you can assess the risk of
introducing a regression on a case by case basis: All I can say is that
I have *never* seen this sort of change carried out without
unanticipated sideeffects. What will the side effects of this particular
one be? I don't know, crystal ball is hazy.

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

I've argued strongly *for* landing the core components of this with no
other dependencies, and I certainly don't think you need to
touch .bzrignore.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080520/5584f8fc/attachment-0001.pgp