[Python-Dev] Mercurial migration: help needed

[Paul Moore]

2009/9/5 "Martin v. Löwis" <martin at v.loewis.de>:
>> FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad
>> requires /r/n, but do IDLE and other editors (on Windows) that people
>> would actually use to create/edit such files? I would personally be
>> willing to install a notepad replacement if needed to quickview such files.
>
> Visual Studio will create files with CRLF endings. Please don't talk
> people out of using Visual Studio for development. More generally:
> please accept that it is consensus that this *has* to be fixed, and
> that it *is* a problem on Windows.

(Disclaimer: I have no problem with accepting that the extension is
needed - the following is for clarity, in particular to help me
understand how the hook will be used)

There are 2 separate questions - (1) what is held in the repository,
and (2) what is in the user's workspace. The two clearly interact.

Taking (2) first, there are *some* files (very few, I believe) that
require specific line endings (CRLF - Visual Studio build files, is my
understanding). There are also tools that require fixed line endings
for input (notepad, Visual Studio). Finally, tools create new files
with certain line endings by default (pretty much guaranteed to be
platform-native, I'd expect). The result is that user workspaces *may*
(quite probably, will) contain files with a mixture of line endings if
care is not taken.

As regards (1), I assume that for "text" files, a consistent EOL
convention (assumed LF) should be used in the repository. It's not
clear to me what should be held in the repo for the files requiring
specific line endings - my instinct is that they should be treated as
"binary" and stored in the repo with the mandated line endings, and
checked out unchanged.

So we have the following situation:

- Some "binary" files which should never be converted
- Some "text" files, which must be held in LF form in the repo

My view is that how I store text files in my workspace is entirely up
to me (and the capabilities of my tools). So, how files get checked
out should not be centrally mandated. (Hmm, that may complicate
matters). How files are checked in is crucial, so a setting is
required which ensures that each file so marked is converted to LF
format on checking - effectively working like universal newline mode.

So, the issues:

1. Given that the "problematic" tools (notepad and Visual Studio) are
Windows tools, we seem to be back to the idea that this extension is
only needed by Windows developers. As I understood the consensus to be
that the extension should be for all users, I suspect I've missed
something.
2. Allowing text files to be checked out in whatever form the user
prefers seems complicated. The alternative would likely be to say test
files are checked out in "native" form. That works, but would irritate
me as I work on Windows, but prefer strongly to use LF line endings
(yes, I realise that makes me an oddball...) I'd put up with it if it
was the consensus to do this, of course.
3. Is there a realistic possibility that a user could edit one of the
CRLF-requiring files with a tool that converts it to LF? If so, is
there a need to trap that programmatically (as opposed to simply
accepting that this equates to the individual accidentally breaking
the build, no worse or better than checking in a C file with a syntax
error)?

Is this a fair summary?

Paul