apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@e-reka.si>
Subject Re: svn:eol-style for autoconf stuff
Date Wed, 16 Feb 2011 23:38:28 GMT
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

View raw message