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

Ian Clatworthy ian.clatworthy at internode.on.net
Tue May 20 09:32:15 BST 2008


Robert Collins wrote:
> 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

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

I agree that principle has served us well. branch.conf is the only
exception I know of. Shell hooks might live under there one day but
don't yet.

>> 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 hope I understand your concerns, namely:

1. Putting data about the tree in the tree is evil. This causes
   ugliness like special hacks in export to skip over it. It also
   makes it next to impossible to abstract how we deliver functionality
   in the future or in custom applications.

2. Exposing metadata like this locks in the format reducing
   upgrade options and forcing us to always carry supporting code,
   however obsolete that format is in the future.

3. The future consequences are unclear but are likely to include
   lower performance.

If I'm missing others, let me know.

On the other hand, we gain rules that are stored per revision, we
get a UI for diff/merge/etc., we don't force a format upgrade on
everyone and users of most popular systems are already comfortable
with managing .xxxignore files this same way, however imperfect it is.

It's a question of trade-offs at some point. I fully agree with
the benefits of typed data. I also think our policy of new semantics
means new format is good. But I can live with limited magic files
at the top of a tree, all marked as ".bzryyyyyy". To give us breathing
room for format bumps, we could introduce an optional format marker
either as a file extension (.bzrrules.v2) or top line of file, e.g.

  # format 1.6

My point is that there are solutions (of varying quality) either way.

IMO, "mistake" is a harsh word - I see it as being less black and
white than that. At some point, our guidelines conflict or imply
lots of work. Take these:

1. metadata in the tree is evil.
2. Users shouldn't edit things under .bzr.

For complex metadata which is best expressed as a config file
complete with embedded user comments, editing this directly rather
than providing a command-line UI for a hidden file is a good choice.
I'd prefer it wasn't in the tree but we don't have an architecture
for many out-of-tree operations on files like this. So, putting some
(potentially format-marked) files only at the top of the tree now
is a trade-off I'm ok with. We're forever carry code for that format
but I think many of the other problems are oversold at times.

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

To give one example, bzr-fastimport puts a file under .bzr for tracking
the map of source rev-ids to repo rev-ids. I use that for restarting
at a checkpoint if the import fails, or for updating a "mirror" repo.
I don't think get_user_option is enough for all plugins.

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

I have no complaints and don't feel you've been blocking me in any way.
I did feel there was no point putting up something you felt
passionately against though. Please continue to argue for what you
feel is right, while understanding that my views on trade-offs
will differ from time to time.

Ian C.



More information about the bazaar mailing list