Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 50397 invoked from network); 27 Oct 2005 17:25:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Oct 2005 17:25:17 -0000 Received: (qmail 15373 invoked by uid 500); 27 Oct 2005 17:25:16 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 15343 invoked by uid 500); 27 Oct 2005 17:25:16 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 15334 invoked by uid 99); 27 Oct 2005 17:25:16 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2005 10:25:16 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 68.142.198.205 is neither permitted nor denied by domain of mcintyre.a@gmail.com) Received: from [68.142.198.205] (HELO smtp106.sbc.mail.mud.yahoo.com) (68.142.198.205) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 27 Oct 2005 10:25:12 -0700 Received: (qmail 32476 invoked from network); 27 Oct 2005 17:24:53 -0000 Received: from unknown (HELO ?192.168.0.5?) (fuzzylogic@sbcglobal.net@68.122.124.89 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 27 Oct 2005 17:24:52 -0000 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <43610354.7000006@sun.com> References: <435E8AF6.3030803@sbcglobal.net> <43609FEF.6050305@sun.com> <4360CF32.1050001@sbcglobal.net> <4360E3E3.9030705@sun.com> <4360E8B2.3040503@sbcglobal.net> <43610354.7000006@sun.com> Content-Type: multipart/alternative; boundary=Apple-Mail-14--344648970 Message-Id: <490F709E-22B8-4DE8-84F0-800AE0EBC5E4@gmail.com> From: Andrew McIntyre Subject: Re: [VOTE] 10.1.2.0 release Date: Thu, 27 Oct 2005 10:24:49 -0700 To: X-Mailer: Apple Mail (2.734) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-14--344648970 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 27, 2005, at 9:41 AM, Oyvind.Bakksjo@Sun.COM wrote: > But if you're in the mood for committing, I have something for you > - you could merge this patch onto the branch - it's getting late > here and I would like to go home and get something to eat.... :o) Sure. >> As for the linefeeds, I think the correct solution is to fix up >> the line feeds for the tars and not the zips using Ant's >> task. I believe that for shell-emulation environments >> on Windows that the linefeeds should still be CRLF, not LF, but >> could somebody confirm that? >> > > I disagree, that would push the problem to everyone building on one > platform and deploying on multiple, for all releases from now and > forever. Any decent shell-emulation environment must IMHO take into > account that shell scripts are LF terminated (at least cygwin > does). Just as any emulator running .bat files on a unix would have > to deal with CRLF. ok, since I don't use Cygwin much, so I didn't know what its behavior would be. For the record, you could still build on any platform and get identical results using , and in fact might be useful for guaranteeing that the line feeds are correct. The task allows you to specify what the linefeeds in a file should be, regardless of the current platform's eol-style, not just fix them up to the current platform. So, as an example, I believe .subversion/config overrides properties in the repostiory, so if someone had svn:eol-style native for .sh and .bat in their .subversion/config, as is currently recommended by http://www.apache.org/dev/svn-eol-style.txt, then .bats and .shs would end up being LF on Linux. We could guarantee that each file has the correct line feeds by running them through the task in the release target before archiving. A better question is what does Ant's tar on Windows do with the executable bit? NT and NTFS don't have one, so what does it do on Windows? We might need to specify the exact expected permissions in those files' in the release targets. I'm actually sort of surprised no one has brought this up before. andrew --Apple-Mail-14--344648970 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Oct 27, 2005, = at 9:41 AM, Oyvind.Bakksjo@Sun.COM = wrote:

But if you're in the mood for = committing, I have something for you - you could merge this patch onto = the branch - it's getting late here and I would like to go home and get = something to eat.... :o)

Sure.

As for the = linefeeds, I think the correct solution is to fix up the=A0 line feeds for the tars and = not the zips using Ant's <FixCRLF> task.=A0 I believe that for = shell-emulation environments on Windows that the=A0 linefeeds should still be = CRLF, not LF, but could somebody confirm that?
=

I disagree, that would push the problem to everyone = building on one platform and deploying on multiple, for all releases = from now and forever. Any decent shell-emulation environment must IMHO = take into account that shell scripts are LF terminated (at least cygwin = does). Just as any emulator running .bat files on a unix would have to = deal with CRLF.

ok, since I don't use = Cygwin much, so I didn't know what its behavior would be.=A0
For the record, you could = still build on any platform and get identical results using = <FixCRLF>, and in fact might be useful for guaranteeing that the = line feeds are correct. The task allows you to specify what the = linefeeds in a file should be, regardless of the current platform's = eol-style, not just fix them up to the current platform. So, as an = example, I believe .subversion/config overrides properties in the = repostiory, so if someone had svn:eol-style native for .sh and .bat in = their .subversion/config, as is currently recommended by=A0http://www.apache.org= /dev/svn-eol-style.txt, then .bats and .shs would end up being LF on = Linux. We could guarantee that each file has the correct line feeds by = running them through the <FixCRLF> task in the release target = before archiving.

A better question is what = does Ant's tar on Windows do with the executable bit? NT and NTFS don't = have one, so what does it do on Windows? We might need to specify the = exact expected permissions in those files' <tarfileset> in the = release targets.

I'm actually sort of = surprised no one has brought this up before.

andrew
= --Apple-Mail-14--344648970--