Paul Moore writes:
> The result is that user workspaces *may* (quite probably, will)
> contain files with a mixture of line endings if care is not taken.
Yes. Under your "fixed-EOL-files-are-binary" scheme, this is
guaranteed for Unix systems.
> 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.
Why? Files that require specific line endings are in general used in
platform-specific ways. So checking them out with the platform's
normal line ending should work fine.
> 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.
Your tools will be able to work with the native EOL convention, or you
wouldn't be able to stand using them. In general the extension should
default to checking out with the native convention. If you really
want to change that, you can; there's nothing the server can do to
mandate what's in your workspaces. The "mandate" here is simply the
default extension that Python and/or Mercurial will distribute to help
developers avoid having their pushes aborted for incorrect EOLs.
> 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.
What you've missed is that developers *of* the Windows port are not
necessarily developers *on* Windows. If we treat these as text files
and check them out in the native convention everywhere, then it
doesn't matter if you edit them on Unix or Windows, when you check
them out and build on Windows it Just Works[tm]. I have never heard
of a Unix cross-IDE port of Visual Studio
> 2. Allowing text files to be checked out in whatever form the user
> prefers seems complicated.
It's not a question of "allow". AIUI, you won't be allowed to push a
commit with broken line endings to the public repo. This is too much
of a burden to impose given the wayward behavior of existing tools, so
an extension will be distributed that does the checking (and any
needed conversion) for you. If you don't like that extension, you can
change it; it shouldn't be too difficult. Eg:
> 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.
You don't need to. In that case I would guess that you are at very
low risk if you disable the checkout side of the extension.
> 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?
Yes. It happened occasionally in XEmacs's CVS repository, and caused
great consternation among Windows testers.
> 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)?
It's worse. Until the problem is fixed, the people who need a
different EOL convention are working with a file with breakage on
every line. Furthermore, that breakage may be quite silent, eg, if
you use XEmacs to edit on Windows but Visual Studio to build. With
Emacs it's easy enough to change -- if you recognize the breakage.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
