> 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 > file. 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 files. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
