Re: [Python-Dev] [Python-checkins] r42929 - python/trunk/Tools/scripts/svneol.py
[Tim Peters]
Added: python/trunk/Tools/scripts/svneol.py (contents, props changed) Log: Simple utility to add svn:eol-style to text files under SVN control. Like reindent.py, I expect to run this mindlessly from time to time, checking in whatever it happens to do ;-)
[Thomas Heller]
Should 'sln' and 'vcproj' be added to the extensions list? I think these are text-files too. Although PCBuild\pcbuild.sln has a binary mime-type property, so the script would not change that.
I don't know whether they're text files in the SVN eol-style "native" sense. The corresponding file types under VC 6 were not: in SVN terms, they should have svn:eol-style set to CRLF (Visual Studio required \r\n line ends for some inscrutable reason -- it would not tolerate \n line ends, and this mattered when, e.g., some Linux-head tried to run Visual Studio from a Linux-native checkout of Python; CRLF was still required, and we "faked that" under CVS by calling those files binary; SVN offers finer control; I don't know how picky the .NET 2003 MSDev is about this).
Tim Peters wrote:
[Tim Peters]
Added: python/trunk/Tools/scripts/svneol.py (contents, props changed) Log: Simple utility to add svn:eol-style to text files under SVN control. Like reindent.py, I expect to run this mindlessly from time to time, checking in whatever it happens to do ;-)
[Thomas Heller]
Should 'sln' and 'vcproj' be added to the extensions list? I think these are text-files too. Although PCBuild\pcbuild.sln has a binary mime-type property, so the script would not change that.
I don't know whether they're text files in the SVN eol-style "native" sense. The corresponding file types under VC 6 were not: in SVN terms, they should have svn:eol-style set to CRLF (Visual Studio required \r\n line ends for some inscrutable reason -- it would not
I know. In CVS, they had to be added using the -kb flag, IIRC.
tolerate \n line ends, and this mattered when, e.g., some Linux-head tried to run Visual Studio from a Linux-native checkout of Python; CRLF was still required, and we "faked that" under CVS by calling those files binary; SVN offers finer control; I don't know how picky the .NET 2003 MSDev is about this).
I remember that someone has tested that the .vcproj files actually did work even if they had the wrong line endings, so it should be ok. AFAIK, noone tried that with the .sln file - anyway, I have removed the svn:mem-type property and the script then set svn:eol-style native. Maybe a different set of svn properties were better, I have to learn about them. The problem that I saw is that 'svn diff' refused to provide a diff when pcbuild.sln had changed - I would consider this diff useful, both in commit-emails as well as run on the command line before checking in. The Linux-head is the release manager, prepaing the release on a unixish platform, in combination with the windows guy who downloads the source distribution and tries to compile that on Windows. Thomas
[Thomas Heller]
... The Linux-head is the release manager, prepaing the release on a unixish platform, in combination with the windows guy who downloads the source distribution and tries to compile that on Windows.
That sounds like an artificial (process-created) problem, then. Since a release should be made from a tag, there doesn't seem a real reason to make the Windows release wait for a source-release tarball to get made (the Windows dweeb should be able to do a native checkout of the tag, and do their stuff in parallel -- that's how I used to do Windows releases, and it worked fine -- the only thing the Windows release serialized on was waiting for the release's final docs to get cut). Setting project files to some flavor of text mode makes sense for your other reasons regardless (like getting useful diffs).
Tim Peters wrote:
[Thomas Heller]
... The Linux-head is the release manager, prepaing the release on a unixish platform, in combination with the windows guy who downloads the source distribution and tries to compile that on Windows.
That sounds like an artificial (process-created) problem, then. Since a release should be made from a tag, there doesn't seem a real reason to make the Windows release wait for a source-release tarball to get made (the Windows dweeb should be able to do a native checkout of the tag, and do their stuff in parallel -- that's how I used to do Windows releases, and it worked fine -- the only thing the Windows release serialized on was waiting for the release's final docs to get cut).
I did it the same way for the 2.3 releases that I made. But I did not mean the official binary Windows installer, I mean someone who downloads the official source tarball, and compiles that himself. There was at least one 2.3 release where one could not compile with MSVC6 from the source tarball because of wrong line endings.
Setting project files to some flavor of text mode makes sense for your other reasons regardless (like getting useful diffs).
Sure.
Tim Peters wrote:
Should 'sln' and 'vcproj' be added to the extensions list? I think these are text-files too. Although PCBuild\pcbuild.sln has a binary mime-type property, so the script would not change that.
I don't know whether they're text files in the SVN eol-style "native" sense.
Last I tried, VS 2003 would tolerate \n line endings in vcproj files (these being plain XML files). I don't remember whether it would tolerate them in .sln files (as these are *not* XML files); this is why the .sln file is set to binary. Regards, Martin
[Martin v. Löwis]
Last I tried, VS 2003 would tolerate \n line endings in vcproj files (these being plain XML files). I don't remember whether it would tolerate them in .sln files (as these are *not* XML files); this is why the .sln file is set to binary.
FYI, I tried changing pcbuild.sln to use plain \n, and it worked fine.
participants (3)
-
"Martin v. Löwis" -
Thomas Heller -
Tim Peters