[MERGE] integrated EOL conversion support

[Alexander Belchenko]

Ian Clatworthy пишет:
> John Arbash Meinel wrote:
> 
>> I'm still a bit concerned that the labels are the "wrong way" around. In
>> that you are setting the line-endings in the repository, rather than
>> settting the line-endings in the working tree. I'm pretty sure other
>> systems like svn have the value indicate the working tree line endings.
>>
>> (At least last I checked, 'crlf' meant native locally and crlf in the
>> repo, rather than whatever in the repo and crlf when I'm working with it.)
> 
> I'm going to wait a day or two before landing this because I want to make
> sure everyone has a chance to raise concerns like this. This is an important
> feature and like many things, it makes a statement about what Bazaar stands
> for: something cleanly designed and well thought through, something far
> less complex than git but more flexible/powerful than Mercurial. (Ducks
> quickly.) :-)
> 
>> I honestly think people care more about the value they get when they are
>> working on the file, because it matters what other tools are going to do
>> with it.
>>
>> I'm certainly not trying to block, just address a possible point of
>> confusion.
> 
> And I understand your point. The problem is that some/many projects will
> define project-specific rules and check them in to their branch or
> version-control them in a separate, shared location that developers will
> be told to point their path to. The moment I deliver custom rules - rules
> defined somewhere else besides each user's bazaar.conf file, then the
> emphasis *must* be first-and-foremost on what get's *committed*, not what
> individual users would like in their working tree. I also
> feel that native-in-the-tree is the most sensible default so specifying
> that is a bit redundant.

Taking in account absence of versioned properties (thanx lifeless)
and optional presence of rules in the tree I'm strongly agreed with Ian point:

"repository eols matter in first place".

When you have no rules bzr will fall back to "exact", i.e. to what committed last
in the repository.

> 
> I'll *gladly* take suggestions for better names and I'm genuinely happy
> to change them if we can get some consensus on the list about better names
> than what I've put forward.
> 
> Ultimately, I think it will come down to how good the help is.
> For those who have not looked inside the patch, the help is attached.
> 
> Ian C.
>