EOL: patch.eol=auto setting

alexrayne alexraynepe196 at lavabit.com
Wed Dec 23 03:02:15 CST 2009



Martin Geisler пишет:
> Indeed, that was supposed to be a feature. Some people really like to be
> able to ensure consistency in the EOLs. Storing the files with
> consistent EOLs has the advantage that the repository looks "neat" even
> without using the extension.
>
>   
yep. i agree with this on another reason - LF eols, more simple vs CRLF, 
and thus more effective on pathc\diff
and any other operations, so it is better to use it at all.

>>> That being said, Mads Kiilerich did suggest that we could support
>>> using different EOL formats for different files in the repository.
>>> Something like this
>>>
>>>   [patterns]
>>>   foo.py = native/CRLF
>>>   **.py = native/LF
>>>
>>> which should mean that foo.py is checked out in native format and
>>> stored in CRLF format, whereas all other Python files are stored in
>>> LF format.
>>>
>>>       
>> as i understand it is not implemented yet. this is close to my
>> request. i can propagate it to mentioned here style as
>>
>>  **.py = native/auto
>>
>> auto (or can be used another word), mean that repostory version format
>> does not affected, and detected from revision file (or cached any
>> handy way) on any request.
>>     
>
> Ah, that's a new idea! I had not thought of this myself, thanks for
> bringing it up.
>
> Let me just explain how I understand your proposal:
>
> * files are not changed in the repository (no new commits)
>
> * files are written with native EOLs in the working directory
>
> * we automatically detect the per-file mapping needed to make the above
>   two points happen.
>
>   
yep. you understand me perfectly. this is accorded to svn eol-handling 
in that the svn look like dont modify repository
revisions, or perfectly hide this modification, anyway if you set 
property eol-style the only change you see by diff is the
setup of property.
i suspect, that svn instead of cleanup revision file just apply 
conversion to LF-eols for repository revision
before any operations with working files, and with operations between 
repository revisions such encoding not need,
therefore no changes in repository. Such strategy allow to change 
eol-style settings any time without side effects in changesets.

> I've not thought of the complications yet, but the big advantage 
the real complication, imho, would be to implement caching of detected 
eols for repository revisions, without caching it must be not
very difficult in addition to Mads Kiilerich proposal.
> I see
> with such a system is that people can begin using it independently: You
> wont have to convince the rest of the team to use the eol extension or
> to tolerate a .hgeol file. Instead you can just enable eol and perhaps
> make an uncommitted .hgeol file to adjust some settings.
>
>   
i agree, such extention should save many time and labour for mercurial 
multiplatform users, and it could be more convinient then even svn
eol-handling.

and for last - bug reports on current release: it has a strange 
behaviour when work under tortoisehg: dialog ViewFileStatus show work 
files diff
sometimes not affected by hgeol, sometimes affected. i dont detect any 
dependency or algorithm for it. explain what i do:
1) i commit .hgeol file; 2) look ViewFileStatus to examine diffs 3) 
rollback commited hgeol, and change it.
this sequence i execute a few times to look how does hgeol understand  
Mads Kiilerich rules.
Maybe this unstable work caused of error on parsing .hgeol? What happen 
if parsing of some string\rules failed?




More information about the Mercurial-devel mailing list