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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> 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

Another category would be something I pushed hard for in Montreal:
versioned *data*.

The idea for this kind of configuration file is that you store the data,
not the file itself.  The representation may or may not match the one in
the working tree.  Then, as new representations for that data become
available, you can change the representation without causing any
semantic breakage.

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

It's true that was a problem, but I don't think it was the fundamental
problem.

The representation of which revisions had been merged was suboptimal,
and we couldn't change it.  It was suboptimal because some of the data
was ambiguous, and it was suboptimal because there was one working tree
file per historical revision.

Even if we had upgraded our representation, we couldn't have changed the
representation used by old revisions, because that would have altered
the shape of the working tree.

> I think Arch did have the problem that it was not clear to users which
> files they were allowed to modify or not.

In fact, there was vehement disagreement among contributors and Tom
about which files could be modified.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINZx60F+nu1YWqI0RAqNBAJ9rN4OquC9i9+7vOVA25Pm7sZraxwCfSi9y
pQHcsuA9lsLHOZvlb85lTY4=
=8xNa
-----END PGP SIGNATURE-----