EOL: patch.eol=auto setting

[Martin Geisler]

alexrayne <alexraynepe196 at lavabit.com> writes:

> Martin Geisler пишет:
>
>> 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.

Good.

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

Yes, Subversion hides the change. See this test:

  http://bitbucket.org/mg/hg-eol/src/tip/tests/test-svn#cl-68

and the corresponding output:

  http://bitbucket.org/mg/hg-eol/src/tip/tests/test-svn.out#cl-55

Subversion is really changing the file in the repository:

  http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.props.special.eol-style

In the description of the 'native' setting, it says that Subversion
store the file with normalized LF format. But this is completely
transparent to the user.

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

Are you using revision 6fd8c3e6ec1f of eol? Before that version, a
change to .hgeol would not take effect immediatedly. If you change
.hgeol, then you can manually issue 'hg debugrebuildstate' to make sure
that the right files show up as modified.

> 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?

Why don't you just try it? Commit a .hgeol file with a syntax error and
you'll get this:

  % hg status
  hg: config error at .hgeol:3: '='

You'll actually not be able to commit a fixed .hgeol file unless you
disable the extension... hmm, we better fix that :-)

Using unknown keywords like "**.txt = foo" is silently ignored, we
should fix that as well.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20091223/6d2dcdcf/attachment.pgp>