db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: [VOTE] release
Date Thu, 27 Oct 2005 17:24:49 GMT

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)


>> 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  
>> <FixCRLF> 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 <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 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 <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.


View raw message