On 17.02.2011 00:11, William A. Rowe Jr. wrote: > On 2/16/2011 4:54 PM, Guenter Knauf wrote: >> Ok, I stop now nerving you since you're anyway not willing to give me a >> technical >> background for your opinion ... > I did... > > Guenter: .sh and .m4 should be retrieved LF formatted > > Bill: Text (.sh .m4 etc) are text. > > Guenter: No, .sh .m4 etc are binary. > > Bill: /boggles > > Text is text, scripts are text, mixed conventions make .diff's nearly > unparsable, > all of which are technical rationals. > > Might I suggest, since you are working with an MSYS toolchain, that you first > investigate why MSYS .sh does not parse text on windows, and yet the svn > implementation for MSYS implementation does not export/check out in the same > unix convention? This is most certainly at odds.
For the record, svn:eol-style is not a text vs. not-text discriminator. It simply tells one little detail about the /representation/ of the text -- that's why it's separate from svn:mime-type. Subversion itself used to keep its *.ds[pw] templates as svn:eol-style CRLF, but we switched them to native fairly recently, and I've yet to hear about any problems. The Windows zipballs are generated with a --native-eol export, and the project file generator is a Python script -- happily eol-style agnostic on all platforms. Yes, we do not keep pre-cooked Windows project files in the tree, we have a generator that takes a single configuration file and generates either makefiles or MSVC project files. Makes life a lot easier. (Why not SCons? Well, one reason is that no-one has taken the time to throw away a working build system and replace it with a new one full of bugs; another is that, if you want to do serious debugging on Windows, having a real project file is a big help.) -- Brane
