[MERGE] integrated EOL conversion support

[Jonathan Gossage]

Ian Clatworthy wrote:
> 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.
>
> 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.
>   
Here is a user perspective on the CR/LF mess we all have to deal with.
If you do things right, what is important that the document arrive in
the user's workspace with the line termination needed for the particular
task at a given time. Generally, the user is going to want the platform
format for line endings but in a heterogeneous environment there will be
times and tools where the user will need to be able to specify precisely
what is required.

It does not matter what the encoding is in the repository, provided it
is always the same, IF the user has full control over the way the
document is materialized in the workspace. I believe this means that
documents should be materialized by default in the standard platform
encoding and the user should be able to override this when necessary.

As for the repository, so long as only one encoding is used it matters
little which one but the platform encoding makes good sense as a default
and the ability to define the encoding for a particular repository will
be desirable.

HTH

Jonathan Gossage