Line ending translation extension

Paul Moore p.f.moore at gmail.com
Fri Sep 11 10:52:50 CDT 2009


2009/9/11 Martin Geisler <mg at lazybytes.net>:
> The way I see it, mentioning a file in .hgeol means that you no longer
> want to manually control the EOL symbols used. Mercurial will take
> complete control over it.

What do you do about wildcards, then? You need to include an exception
mechanism, or

** = whatever

"mentions" every file, and you immediately need a way to "unmention"
those files where you want manual control. I'm not saying there isn't
a way, just that you need to be explicit about how it's done.

> So even if you change EOL format in a file in
> your working directory, the file wont appear modified to Mercurial. When
> you commit, newlines of all kinds are converted to the format specified
> in .hgeol:
>
>  windows: convert LF and CRLF to CRLF
>  unix:    convert LF and CRLF to LF
>  native:  convert LF and CRLF to repository native format
>
> When you checkout, files are converted as follows:
>
>  windows: no conversion (already in CRLF format)
>  unix:    no conversion (already in LF format)
>  native:  convert LF and CRLF to OS native format

No, internal format should always be the same (probably LF). Life gets
scarier if you have to deal with situations where using the hook isn't
mandated (as then, a standard internal format isn't mandated) - but
that's not relevant for Python.

> By the way, if you change the declared EOL format of a file by editing
> .hgeol, you have to call 'hg debugrebuildstate' to make Mercurial
> double-check the filter settings and doing a commit.

That's *got* to be wrong. There's no way that requiring a debug
command for a user-level operation is reasonable. If it can't be done
with a normal Mercurial command (just check out again, for instance)
then you need to make a user-level command (hg rebuildeol?) available
from the extension.

>> Actually being able to set a required extension was one of the issues
>> brought up in the python-dev list as a requirement for this to work
>> "as expected".
>
> I read that discussion, and from what I remember, then this wasn't a key
> point. Currently the Python developer guide asks people to add a
> [auto-props] section to their ~/.subversion/config file:
>
>  http://www.python.org/dev/faq/#what-configuration-settings-should-i-use
>
> I guess this is for new files. I hope asking them to enable an extension
> wont be a problem then.

My understanding is that the python-dev requirement is that users will
be expected to enable the extension. The behaviour of things when the
extension is not enabled can be considered "undefined" (in the C
standard sense - do what you please, python-dev won't care). Of
course, sane behaviour if the extension is not enabled should be
considered a quality of implementation matter. (Hence the
repo-internal format should be LF, as that's native for Unix users and
generally sane enough, or at least a known insanity, for Windows
users. Don't use a repo-internal format with U+2028 as the line ending
as no-one would consider the results "sane" in that case :-))

Paul.



More information about the Mercurial-devel mailing list