On 2/16/2011 10:11 AM, Guenter Knauf wrote: > Am 16.02.2011 16:48, schrieb Guenter Knauf: >> proposal: >> change all *.sh, *.m4, buildconf* and configure* scripts to >> 'svn:eol-style LF' >> result: >> a svn checkout will allways treat these files with LF format regardless >> of what svn thinks is native for the platform, and this seems correct to >> me. >> >> side effect: >> the _only_ side effect would be that it is then _required_ on windows to >> use a developer editor which supports LF formated files for editing >> autoconf files; but I cant imagine that anyone developing on windows >> platform uses an editor which is not aware of LF formatted files. For >> _all_ other platforms there would be no change since they anyway default >> to 'svn:eol-style LF'. > > another observation on this topic: > http://www.apache.org/dev/svn-eol-style.txt > this config file suggests that we should treat *.ds? files as CRLF, and this > is pretty > much same as what I suggested for the autoconf files ... > though at least APR/APU doesnt follow this recommendation, and *.ds? files are > 'svn:eol-style native' in svn repo.
This is precisely incorrect advice, neither apr, httpd nor tomcat are party to such nonsense (which makes the recommendation REALLY odd, because I'm just wondering who's left?) Have you ever tried to apply a patch containing diffs of files in alternating line end conventions? Surely not, or this nonsense wouldn't be debated. Preserving this metadata when moving files around, say between svn and git? Be real. The advise is wrong for the same reasons as LF format on Windows is wrong. Look, I started at these projects (helped start apr) when the windows guy was the windows guy, that aix guy was the aix guy, and on, and on, and on. It was horribly broken and the chances of building on all platforms at any given time was pretty slim. Today, dev@ who work with windows are willing to take a best guess at some config.m4 change, and our unix dev@ kin are willing to stub in what seems to be a proper .dsp file, just to see if it works. That is where we want to be, so all nonsense to the contrary particularly ticks me off, and that goes in both directions (win32 or unix text files). If you read the 100's of messages in the archives, you will be well aware this is a dead horse, and painting bikesheds is also very irritating. I'm sorry if your sh, m4 ports all disrespect the native machine convention. But if you will use an entirely faux-unix environment on win32, it is incumbent upon *you* to similarly use a faux-unix port of svn, and obtain faux-unix files for your consumption. I know they exist, but as two options... > Although I **dont** want to suggest now here that we chance that - *if* the > *.ds? files > were 'svn:eol-style CRLF' in svn then our daily snapshots would work for > Windows MSVC > users too. If this is about snapshot builds, and checking out images on the wrong platform, then I want to be certain you are aware of the svn export --native-eol feature? It's trivial to post both .tar.gz and .zip files from our snapshot'er. If you arrive at the wrong flavor, it's also trivial to use srclib/apr/build/lineends.pl to correct the entire image in one whack, and it works in either direction on whichever OS you have (implicitly preferring to convert to the local convention). Daily snapshots of trunk won't work for anything automated, because we don't maintain fungible frequently-changed .mak files in svn until after the sands stop shifting (at a .even minor release), at least in new APR convention. Was already expecting to move this convention into 2.0/2.2, and heck, even check in an already ported .sln file (although -which- of many .sln/.vcproj formats is the ugly question to be answered, first). All this is something to improve upon, sure, but I don't want anything as munged as PHP's bizzaro .js config.win craziness, and there is still some work to do before we have the complete scons solution, but none of it supports wasting more bandwidth on absurd arguments that text is not text. /sigh
