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

[Martin Pool]

On Tue, May 20, 2008 at 11:01 PM, Aaron Bentley <aaron at aaronbentley.com> wrote:
> Stefan Monnier wrote:
>> I'm probably sounding like a broken record, but in any case I'll restate
>> that I think the Arch way was right:
>> - treat it like a normal user file (w.r.t merging, changing,
>>   committing, ...).
>> - but place it somewhere inside the .bzr directory.

So we have at least five categories of possible file, the first four
of which we use at present:

 0- internal files: inside .bzr; users should never touch it;
rewritten by upgrades; propagated according to semantic rules; read
and updated only by abstract apis and commands, not directly

 1- source files: regular user data; not in .bzr; we never rewrite it
and it's merged as a text file with no special interpretation

 2- .bzrfoo files: the only example at present is .bzrignore; just
like source files but they affect bzr too

 3- eg branch.conf: users may edit it and stored verbatim; not
propagated at all; read by bzr (but this is a bit of a strange fish)

 4- what Stefan proposes: just like a .bzrfoo file but stored inside .bzr

The main advantage of the last seems to be: less clutter in the source tree.

> Do remember that several of bzr's designers are former Arch
> contributors.  I found that Arch's way seemed very clever at first, but
> it tended to break in the edge cases.
>
> For me, the biggest example of this was Tom Lord deleting log files,
> which were the main indicator of which revisions had been applied, from
> the tla-dev.
>
> Another was users' editing of those log files-- they would do this to
> fix commit messages, or to change branch names.  But they usually did it
> wrong-- they didn't update the corresponding archive logs, for example.
>
> Another example was the log files themselves.  Their format for tag
> revisions was ambiguous, but since their data was represented as files,
> there was no way to update them without also changing the tree content.

So I have less experience of Arch than you, but it seems to me the
real problem is not so much that they were in the tree but that they
were denormalized.  There are multiple copies of the file but no clear
statement on how they should propagate or merge, or what could or
could not be done by mutating them.

I think Arch did have the problem that it was not clear to users which
files they were allowed to modify or not.  Though the transparent
storage format is very attractive in some ways, it does exacerbate
this, as did the documentation style of pointing out what's under the
hood.

-- 
Martin <http://launchpad.net/~mbp/>