[Python-Dev] Mercurial migration: help needed

["Martin v. Löwis"]

> 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.
[...]
> As regards (1), I assume that for "text" files, a consistent EOL
> convention (assumed LF) should be used in the repository.

Correct. I believe Martin (the other one) proposed to make it
configurable. I agree that using LF in the repository is sensible.

Wrt. "should": there is the debate whether intermediate revisions
can deviate from that requirement.

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

I would say so, yes. One consequence of that is that if you change
your mind in hgeols, you need to commit all files that now fail to
conform. This is what happens with svn, and it may be tricky to
implement as you need to commit files that didn't change on disk
(say you switch from native to CRLF on a Windows checkout).

OTOH, even if you do store all text files in LF in the repo, then
you would still have the problem for files that go from unspecified
eol-style to a specified one. So changing hgeols is tricky, period.

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

Not by technical means, no. In the developer FAQ, there will be clear
directions, and you better follow them - or need to accept the blame
if you made a mistake because you ignored them.

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

Technically, yes, it is only needed on Windows. The desire to have
all users use them come from the wish that problems with the setup
will be detected earlier. E.g. if the extension stops working with
a new Mercurial version, and all users use them, there is a larger
motivation to fix them for all users.

Things that the extension can do for you on Unix:
- check that the syntax of .hgeols is correct; this may affect
  Unix users which try to edit it
- check that all text files have consistent line endings, and
  refuse checkin if they don't. This may become relevant if
  a Unix text editor tries to edit a CRLF file, and doesn't
  quite detect that.

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

It's consensus, and it's also what subversion does, and CVS did.

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

I think everything you can imagine is also realistic. For the
less-realistic cases, it may be better if the commit is refused rather
than silently fixing it, since the user operated the system in a
surprising way - so he may actually have meant to do it that way.

One specific case is recent autoconf, which put a CR character
into configure, completely breaking svn's eol handling.

Regards,
Martin