[MERGE] per-user file properties

[Talden]

>  | This patch provides the plumbing for finding and reading per-user file
>  | properties. This feature is a building block for EOL support. However,
>  | it has been explicitly designed to be a generic capability and ought to
>  | be suitable for configuring other interesting things like custom diff
>  | and merge algorithms.
>  |
>  | Properties are defined in the BAZAAR_HOME/.bzrproperties file using an
>  | ini file syntax where the section headings are patterns and the section
>  | contents are the properties. Patterns use the same syntax as that used
>  | by .bzrignore files. Here is an example:
>  |
>  |   [*.py]
>  |   eol = exact
>  |
>  |   [*.pdf]
>  |   text = False
>  |
>  | Note that patterns are explicitly ordered - the first one matching wins.
>  | This implies that more explicit patterns should be placed at the top of
>  | the file and more general patterns towards the end.
>  |
>  | In the future, core features and plugins can assign meaning to various
>  | properties. Doing that is beyond the scope of this patch.
>  |
>  | A future enhancement may also support .bzrproperties files in places
>  | other than BAZAAR_HOME. If and when we decide to do that, I think that's
>  | a small change code wise (over and above this patch). For now, the
>  | consensus is that we should first gain experience with a simple
>  | implementation of file properties (e.g. the one proposed by this patch)
>  | before introducing the additional complexity implied by the various
>  | extended schemes.

>  How does this work on a repository basis? It is not a good idea to
>  expect every user to configure this correctly and some files with the
>  same pattern may have different line ending styles in different
>  repositories. Storing the line ending style in the branch itself would
>  be much better and more flexible. A property should be really tied to
>  the file and not stored somewhere else. Otherwise when the file moves or
>  the extension changes then the properties may also change.

I think this is a reasonable means of getting EOL transformation out
to users promptly.

I think the idea of using patterns is an excellent fit for dealing
with the number of different rules but as I've stated in an earlier
presentation of this same concept, Bazaar needs to track activities
such as moves and support exact matches as well as patterns to capture
when files move out of a pattern.

That is, if a file foo.txt was matched by *.txt and is moved to
foo.txt.bak then we might want bazaar to add a rule that matches that
file exact to ensure that the properties it had follow it.

Removals can remove exact matches from the properties rules.

so the rule

[*.sh]
EOL=LF

that matched 'scripts/foo.sh' changes when we do a move to 'scripts/foo.sh.old'

[scripts/foo.sh.old]
EOL=LF

[*.sh]
EOL=LF

If we now move it to 'scripts/bar.sh.old' the rules change again
removing the old exact match and replacing it with the new one.

[scripts/bar.sh.old]
EOL=LF

[*.sh]
EOL=LF

The same application applies as suggested in the OP.  The first
pattern that matches wins, except that exact matches are always tested
first.

Naturally this splitting out of exact matches from patterns has it's own issues:

1. if you add or change properties in the *.sh pattern later those
won't flow to the renamed file.
2. If an exact match moves back into it's matching pattern it won't
rejoin the pattern (this could be done though by rejoining whenever it
matches a pattern and the properties are the same as the exact match.

This model may not work as well for general properties as it should
for EOL rules where files don't tend to change their EOL rule over
time and so these issues are less relevant.  The good thing is, when a
better EOL solution comes along it should easily be able to scrape
this properties definition for initial settings.

--
Talden