[MERGE] integrated EOL conversion support

[Alexander Belchenko]

Jonathan Gossage пишет:
> Ian Clatworthy wrote:
>> Matt Doran wrote:
>>
>>   
>>> I do agree with Jonathan.  I can't see why the repository format is
>>> important.  (I guess choosing the repo format that most closely matches
>>> your environment will reduce the amount of translation of these files
>>> between the checkout and the repository ... and hence performance? ...
>>> is that the justification?)
>>>     
>> Repository format is important because:
>>
>> 1. It determines what gets checked out in the absence of any rules.
>>   
> If you make the internal default for the repository be the native
> platform encoding and the workspace encoding in the absence of specific
> rules also be the platform encoding, you will cover a substantial part
> of the total user base without needing specific rules.

I don't understand this.

People who work only on single paltform (no matter Linux or Windows) no need
for eol at all. They already have files committed in their native encoding.

Eol support required for cross-platform projects *only*.

>> 2. Projects have existing files with crlf committed and we don't want
>>    to normalise all existing files to a single internal convention:
>>    that would cause annotate and other commands grief because all
>>    text files using something other than lf now would essentially
>>    "reset" w.r.t who contributed what lines.
>>   
> One possibility for existing repositories containing files with
> non-native encoding would be that they continue to be stored in the
> repository with their existing line end encoding and that they be
> transferred to/from the user workspace with the repository encoding. If
> the user overrides the current encoding then the new encoding should be
> used when the file is returned to the repository. It might be nice to
> provide a  command for those users who choose to migrate to standard
> settings to perform the conversion in a single step. Documentation
> should then point out the possible consequences of such migration.

I don't think so.

>>   
>>> I found a recent merge request for tree-specific-rules.   Wouldn't this
>>> be required for large projects to set a consistent EOL policy?
>>>     
>> That patch has been abandoned for a new, more flexible approach. See
>> http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/51347.
>>
>>   
>>> I'm not sure how familiar you are with the subversion approach. I'll
>>> explain it briefly.  I'm not saying their approach is perfect, but it
>>> works pretty well, and gives you another perspective.
>>>     
>> Thanks. I had read over it a year back but it's nice to be reminded.
>>
>> Ian C.
>>
>>
>>
>>
>>   
> 
> 
>