[Python-Dev] PEP 385: the eol-type issue
"Martin v. Löwis"
martin at v.loewis.de
Wed Aug 5 09:45:18 CEST 2009
> If things were different, they'd be different. However, we live with the
> legacy of that stupid set of decisions and have no real option to
> resolve it permanently short of deprecating entire vistas of tools (or
> even entire operating systems).
I think you missed the solution to the problem that Mark proposed
(IIUC): a local commit to a hg repository should already get the line
endings right, by automatically converting the file-to-be-committed
into the repository line endings. This is what CVS has supported for
more than ten years, and what svn supports for close-to ten years.
> * distributed VCS has the job of preserving data as present on the
> filesystem, including whatever line-ending convention is present in a
No, that's not true. Distributed VCS has the job to help the developer.
That may mean to preserve the file as-is, or it may mean to convert the
file on checkout and checkin. Which of these would be needed depends
on the file, of course.
> It's not a simple thing to solve, and many clever people have tried over
> the decades. The fact that a centralised VCS can put the problem aside
> by requiring an explicit, single decision in the repository, is no help
> when addressing the constraints of a distributed VCS.
Why do you say that? It's not true. The approach that has worked for the
central repository can work just as well for a distributed repository.
> At some point, the decision about how to handle line endings in
> cross-platform data needs to be punted to a human for a
> context-sensitive assessment, since (as can be seen) the above list of
> requirements is internally inconsistent and can't be relegated to a
> one-size-fits-all algorithm.
Right - there needs to be a way for the user to specify what line
endings to use. That's why both CVS and subversion have supported such
configuration, on a per file basis, for many years. I can't see why
hg couldn't, in principle, support the same configuration. Being a DVCS,
such configuration would have to be part of the clone, of course, being
versioned, and all that. I think hg is well capable of keeping versioned
configuration information in the clone, as demonstrated by the .hgignore
More information about the Python-Dev