EOL: patch.eol=auto setting

[Martin Geisler]

alexrayne <alexraynepe196 at lavabit.com> writes:

> Martin Geisler пишет:
>>
>> The main advantage is that eol keeps its configuration settings in a
>> version controlled file.
>
> i can store win32text settings in repository local hgrc file too.

I'm talking about putting the files in a version controlled file. That
way settings will travel along when you push and pull, just like the
ignore settings stored in the .hgignore file.

> i imagin yet another examples:
> 1)if people makes a mistake when cleanup commits and this mistake
> detected too late, this require
> repair commit on commit, and with every commit repository will grows
> rapildly.

No, don't be alarmed. First, you will only do one repair commit per
file. You wont be doing it again and again... Second, the repository
wont double in size. I just tried importing all files in Mercurial's own
repository in a fresh repository. That gave me a .hg/store of 5.8 MiB. I
then replaced \n with \r\n in all files and committed. The .hg/store
folder was then 7.4 MiB. That was with 234,000 lines of code.

> 2) if repository shared between many peoples, some of them use hgeol,
> some not. peoples used hgeol make cleanup commit - now how they are
> push\pulling between each other? their changesets affects all the
> repository.

You should only use the eol extension if you actually think it is a good
idea to have a consistent repository. Consistent in the sense that, say,
all *.py files should have CRLF format. If you like to have an
inconsistend repository, then don't use the extension :-)

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.

> the reasons why repository format should be untuched maybe different
> for other peoples.
>
> anyway impementing the basic smart encoding is not very difficult
> feature - must be implemented one more testing of retrieved repository
> version. imho, this feature can be very useful just because it allow
> repository be untouched, and therefore provide people feeling of
> safety - without cleanup commits there no trash changesets or mistakes
> go into repository. and it is real advantage vs win32text.
>
> maybe i must say PLEEESSSSEEE, provide smart encoding in hgeol.

Please be more specific -- I can only guess what you mean by "smart
encoding". The filters are already somewhat smart in the sense that they
wont touch files that contain NUL bytes ("binary" files) or files with
inconsistent line endings (a mix of \n and \r\n).

-- 
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/20091222/abf8b677/attachment.pgp>