[MERGE] integrated EOL conversion support

[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.
> 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 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.
>
>
>
>
>