[MERGE] line-endings support: part 1 of 2: versioned properties

[Alexander Belchenko]

Nicholas Allen пишет:
> | E.g. if you have many C-files then you need to set only one property 
> section
> |
> | bzr prop-set *.c foo bar
> Shouldn't that be "bzr prop-set foo bar *.c"?

All prop-commands use arguments sequence as

FILENAME_OR_PATTERN PROPNAME [VALUE]

I don't see reasons to reshuffle them.

> 
> |
> |> Personally, I think it would be better to have a separate file for 
> "automatic properties" that are set when adding files (by matching them 
> with a file name pattern) but which do not apply to files that have 
> already been added and are under version control.
> |
> | I think we don't need such "automatic properties" at all.
> | It's not svn properties, it's bzr properties.
> Ok - I am used to using Subversion so maybe I'm locked into this way of 
> thinking. Your approach could be better but I have not used it in 
> practice so it is hard for me to say. I'm worried if adding a wildcard 
> section could affect some files you did not intend to change but maybe 
> this would not be a problem.

Either approach has pros and cons.

> |
> |> Also I think the problem with conflicts in this file would be a bit 
> annoying. New properties will be added at the end I guess and so if 2 
> branches set properties (even on different files or different 
> properties) this will cause a conflict. I realize this is a limitation 
> of your simple approach but I wonder if this would be too annoying to 
> use in practice. Especially, as bazaar has the automatic gatekeeper as a 
> workflow - I think this would cause unnecessary conflicts that would 
> make this workflow not useable anymore because the gatekeeper could not 
> automatically resolve all these conflicts.
> |
> | I expect that file with properties will not be changing too often, as 
> I explain
> | above new copy of properties will not be auto-added for every new file.
> Good point. As long as people don't use it in the svn way of setting the 
> properties on each individual file instead of using wildcards. I guess a 
> special merge algorithm could be written for this file that handles 
> these cases without conflicts though - couldn't it?

There is already Merge3TreeBzrProperties class. It's just not completely
integrated with textual merge algorithm at this moment. I hope this
will be improved in the near future.