FW: Re: EOL: patch.eol=auto setting

[alexrayne]

Martin Geisler пишет:
>
>>> i cant beleave that you checkout .hgeol every time for take hgeol
>>> setting, i suspect you use working copy of .hgeol, so why you need
>>> commiting one? just for sure?
>>>       
>
> I've tried to explain it already: we want to carry the .hgeol file
> around with clones, similarly to how .hgignore is moved around. 
hgignore is not required to be under version control, and this is very
helps to work with it - i always can
calculate what .hgignore realy do because i shure that current work
version always used, so i shure what i have.
if i think that it should be passed to other people, i always can commit
it, no problems here
> This was
> the main complaint people had about win32text, or at least that's how I
> understood it. Another major problem was that patches generated while
> win32text was enabled were wrong:
>
>   http://bitbucket.org/tortoisehg/stable/issue/82/
>
> This is hopefully solved with the new patch.eol=auto setting.
>
> Please understand that I've never used win32text -- I only work with
> repositories that are consistently in LF format these days. But the
> Python guys complained that anything less than what Subversion is
> offering would not do. So that is why I try to make a new extension that
> can replace win32text.
>
>   
one big differences of svn and hg, imho, we are undervaluate - svn is
central repository system, hg - distributed.
so some tech even with eol-handling good for svn, may not work\or work
bad in hg.
to illustrate it i talk about cleanup commit and distributing of .hgeol.
for svn this operation once done automaticaly stay repository-consistent
and distributed
for all. mercurial cant guaranty that this operation is done ONCE by ONE
commiter and automaticaly distributes
for all. therefore techniq of using cleanup and .hgeol commiting, imho,
can be producted anly after some period of
havily use, and before this expirience achieved should be implemented
safe and compatible methods, as i understand
this methods must not affect repository and must not depend on
repository state.
therefore i vote for rules like some=native\auto

> You might want to go back in the archives and read the discussions we've
> already had about win32text:
>
>   http://markmail.org/message/yj4so736t4cfdulv
>   http://markmail.org/thread/5volevnxgaisx2sc
>
>   
wow, - i can read it very very long.
>> imho, at least for simplify debugging hgeol better to provide some
>> setting (maybe in hgrc) that turn off checking that .hgeol under
>> version control.
>>     
>
> Sure -- I've just pushed a change that makes eol look for .hgeol in the
> working copy first, and then in the tip revision if there is no .hgeol
> in the working copy.
>
>   
how it can be? if .hgeol exist in tip revision, then it automaticaly
appear in work dir after update.
if i delete .hgeol by some reason, i expect that if it is not in work -
then it is not play, but for my
surprice it play like a ghost, like soul of one deleted file comes from
other-world. i see strange diffs,
to ensure i look for .hgeol, see that it is absent in work dir, and
starts thinking deeply about anything
else,and write issue reports....