[MERGE] integrated EOL conversion support

[Matt Doran]

Ian Clatworthy wrote:
> Jonathan Gossage wrote:
>   
>> Ian Clatworthy wrote:
>>     
> Thanks for the feedback Jonathan. I think you're confirming what John is
> saying: people mentally think about the working tree format as their
> priority even if the collective "project" cares more about what's stored
> in the VCS repository.
>
> Several people, John included from memory, have suggested using compound
> names like native-lf, crlf-crlf, etc. where one part is the WT format and
> another part is the repo format. If we do this and put the WT format first,
> we get:
>
> * native-lf   (instead of lf)
> * native-crlf (instead of crlf)
> * lf-lf       (instead of lf-always)
> * crcf-crlf   (instead of crlf-always)
> * exact.
>
> Would those names be better and reduce the potential for confusion?
>
>
>   
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?)

I'm I right in saying this is driven completely from the local client 
configuration?  Or is there some repository state to indicate what rule 
has been applied to a given file?   

I found a recent merge request for tree-specific-rules.   Wouldn't this 
be required for large projects to set a consistent EOL policy?


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.

It's completely driven from a file property named "svn:eol-style".  This 
is set on a per-file basis, and drives how subversion handles the EOLs 
in that file.   The options they provide are: native, CRLF, LF, CR.   If 
the property is not defined, then subversion justs commits the file 
as-is (no special EOL handling).   If the property is set then it will 
verify that the EOLs are consistent in the file before committing (no 
mixing of EOLs), and will then normalize the data to use LF in the 
repository.   When a user checks-out a particular file to their working 
copy, subversion will translate the file from the internal LF format to 
the specified EOL style, or the native format if "native" is specified.  
Subversion also has a mechanism to set default file properties based on 
file extension.  So when you add a new file the eol-style property will 
be set based on the extension and client configuration.  You can read 
about their approach in their book here: 
http://svnbook.red-bean.com/en/1.5/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style

So for most text files, you just set the eol-style to "native".   For 
some files (windows batch files, old Visual Studio project files, shell 
scripts, etc) you can force the format required.

The pros are that it will not do any modification to my files unless I 
explicitly ask for it by setting the EOL style.   This helps where 
committing "binary" files ... you know they won't be be 
modified/corrupted unless you explicitly set the eol-style.   You can 
also see which files have this property set in the repository.     The 
downside of their approach is that it's hard to set/enforce a 
per-project policy.   If a user doesn't have their "auto-properties" 
configuration set correctly the eol-style property will not be set.   
You can enforce it through commit hooks ... but it could be easier.

I'm confident you guys will get the design right.  And just wanted to 
give another perspective. :)

Cheers,
Matt