[Python-Dev] Mercurial migration: help needed

["Martin v. Löwis"]

> I suggested a new extension for two reasons:
> 
> * I'm using Linux, and I mentally skip over all extensions that mention
>   "win32"... I guess others do the same, and in this case it's really a
>   shame since converting EOL markers is a cross-platform problem: if
>   someone creates a repository on Windows, I might find it nice to
>   translate the EOL markers into LF on my machine.
> 
>   As far as I know, all my tools works correctly with CRLF EOL markers,
>   but I can see the usefulness of such an extension when adding new
>   files (which would default to LF unless I take care).
> 
> * A new extension will not have to deal with backwards compatibility
>   issues. That would let us clean up the strange names: I think
>   "cleverencode:" and "cleverdecode:" quite poor names that convey
>   little meaning (and what's with the colon?). We could instead use the
>   same names as Subversion: "native", "CRLF" and "LF".
> 
>   The new extension could be named 'convert-eol' or something like that.

Thanks for the confirmation - this is also why I think a new extension
would be best. FWIW, in Python, most files would be declared native,
some CRLF, none LF.

>> 2) These same recent discussions about an entirely new extension and
>> no clear indication of our expectations regarding what the tool
>> actually enforces means I'm not sure how to make a start on the more
>> general issue.
> 
> It would be a folly to require all files in all changesets to use the
> right EOL markers -- people will be making mistakes offline. The
> important thing is that they fix them before pushing to a public server.
> 
> So the extension should do that: either abort commits with the wrong EOL
> markers or do as Subversion and automatically convert the file in the
> working copy.

Maybe I misunderstand: when people use the extension, they cannot
possibly make mistakes, right? Because the commit that gets aborted
is already the local commit, right?

Of course, it may still be that not all people use the extension.
I think this is of concern to Mark (and he would like hg to refuse
operation at all if the extension isn't used), but not to me: I would
like this to be a feature of hg eventually, in which case I don't need
to worry whether hg enforces presence of certain extensions.

If people make commits that break the eol style, we could well
refuse to accept them on the server, telling people that they should
have used the extension (or that they should have been more careful
if they don't use the extension).

I think subversion's behavior wrt. incorrect eol-style is more subtle.
In some cases, it will complain about inconsistencies, rather than
fixing them automatically.

Regards,
Martin