From dev-return-13355-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Dec 09 23:48:21 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 68903 invoked from network); 9 Dec 2004 23:48:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 9 Dec 2004 23:48:21 -0000 Received: (qmail 34553 invoked by uid 500); 9 Dec 2004 23:48:19 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 34518 invoked by uid 500); 9 Dec 2004 23:48:19 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 34503 invoked by uid 99); 9 Dec 2004 23:48:19 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Errors-To: Message-Id: <6.2.0.14.2.20041209173111.05d85958@pop3.rowe-clan.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 09 Dec 2004 17:47:30 -0600 To: Branko =?iso-8859-1?Q?=C4=8Cibej?= From: "William A. Rowe, Jr." Subject: Re: Compilation on Windows Cc: dev@apr.apache.org In-Reply-To: <41B8D564.7060503@xbc.nu> References: <41B882A8.4060100@lri.fr> <41B8C6C4.3000805@xbc.nu> <6.2.0.14.2.20041209161518.04af7db8@pop3.rowe-clan.net> <41B8D564.7060503@xbc.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N At 04:44 PM 12/9/2004, Branko =C4=8Cibej wrote: >William A. Rowe, Jr. wrote: > >>At 03:42 PM 12/9/2004, Branko =C3=84=8Cibej wrote: >>=20 >>>Tangui Morlier wrote: >>> >>>By the way, folks, why on earth do those files have svn:eol-style set to= "native" instead of "CRLF"? >> >>* because they contain text >What's that have to do with the end-of-line style? Yes most linux editors, at least recent ones, recognize dos line endings. But those are not linux text files, and on older OS's - they become harder to maintain. >>* because 'patch' should always 'just work' >>=20 >It has for me. I've not yet seen a version of patch (on Unix) that would= get confused by the CRs. Apparently you don't do AIX 4.3, HP/UX and other twisted varients lol. >>* because other platform maintainers may add/delete sources >So? They can use a non-broken editor, such as Emacs, vim, etc. It's unix'es editors job to recognize silly MS conventions? >>* because .dsp/.dsw are only the 'obvious' problem. The less >> obvious issue is that the compiler gets entirely twisted about >> what 'line number' of the sources corresponds to a given >> symbol, and the debugging support becomes worthless with \n >> terminated sources. >Huh? Which compiler? And what does that have to do with the=20 >format of .dsp files? Has to do with the format of all text files built by MS cl. A broken build is a broken build, whether it just won't build at all, or when the build results are mildly bogus by being impossible to debug/trace etc. >>apr/lineends.pl exists for this purpose. >It existed for this purpose while we were using CVS. Many people argued= against putting the -kb flag on DSP files, and I sort of agree with that.= However, Subversion is quite a bit smarter than CVS. I'm coming to learn that, though I'm still not reassured. Better point though; svn unix users (or the cygwin port users) can add a flag to their checkout to grab files as CRLF. There's no need to even use the win32 svn port to accomplish this. >I'd like to see concrete examples of problems that can't be worked around.= This hand-waving and inventing problems bores me. I've been using= Subversion with CRLF eol-style set on .dsp files for years, from both= Windows and Unix, and I've never had a single problem. I deal with about 6 different 'edgy' unicies, which aren't nearly as forgiving as Linux. There are alot of broken projects which focus only on the expected Linux/OSX/Win32/Solaris8+ and don't even know what an .sl file is, year old projects who can't grok .dylib files, etc... while our=20 APR project attempts to be wildly more cross platform. Simple fact (again, cvs, and svn may prove better) - In order to patch mixed source and .dsp files as one update against, say, cvs-php4, it's impossible to apply the same patch, checked out on hpux, linux, solaris, and win32. It works just dandy on win32, they all come out with cr/lf's, patches included. Try that on hpux for example, and it chokes. But much worse, try a cvs diff on unix, and you end up with a mess of ^M's on the patch. Now, commit that patch, check it out on win32, and you end up with the beautiful CR/CR/LF line endings. This isn't getting any prettier. SVN has it's own issues. Do an svn diff of a text file (native.) Guess what? The resulting patch isn't even native! On win32 I'm left with LF delimited deltas. Obviously, I won't be ditching=20 lineends.pl any time soon. The cli-dev@httpd project's httpd/mod_aspdotnet repository is actually a nice place to play with these issues; we only build that module on Win32, so almost every issue I mentioned is moot. I'm struggling to see how svn is helping us and what it can do=20 to seriously help Win32 users. Bill