httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: 2.0.23 tarballs up
Date Mon, 13 Aug 2001 16:43:22 GMT

> William Wrowe, Jr. wrote...

> A text file is a text file is a text file.

Actually... in the world I live in... there seem to be UNIX
text files and there seem to be DOS/Windows text files.
They really are 'not the same' as far as a lot of editors
and other programs are concerned.

> If I'm on a 390, I have a bunch of ebcdic files.  So what?  They are text.
> They don't go into a repository as binary, unless they have some really 
> bizzare formatting or escapes in them.

Exactly... and the fact that if you make even the slightest cosmetic
change ( EOL included ) to MSVC .dsw or .dsp then they could
stop 'working' where they are intended to work ( Non-Nix platforms )
can be construed as 'bizarre formatting' and better off being excluded 
from the constant UNIX FTP ASCII text auto-grok stuff. Why take the 
chance at changing the files when there is no need to?

> There will be no binary .dsp or .dsw files in cvs.  ever.
> Bill

Ok... whatever... but watch those LF-onlies gotchas at
release time.

Remember that if the very first line of a .DSW does not end
with CR/LF then MSVC won't even load it and if the 
section/tag names do not terminate with CR/LF you get
error message: "This file was not generated by MSVC".

Unless someone downloads with the specific WinZip product and they
happen to have the Misc|Options|Translate LF to CRLF in TAR files
option turned ON then the .DSW and .DSP coming out of CVS
won't do squat.

Geez... doesn't CVS have some kind of 'Yea... it's a text file...
but leave the line endings alone fer chrissakes because they
just might be important' option somewhere in the config?

Later...
Kevin Kiley

In a message dated 01-08-13 15:17:20 EDT, you write:

> From: <TOKILEY@aol.com>
> Sent: Friday, August 10, 2001 7:02 PM
>  
>  
>  > I think once the original Win32 project files are stored 'as-is' into
>  > the tarball ( as binary versus text to preserve CR/LF ) then this is
>  > all a moot point and both PKZIPW and WinZip will produce a 
>  > loadable Apache.dsw project. That's the way it's always been
>  > but I might be the only one left using PKZIPW for Win32 so 
>  > it probably doesn't matter.
>  
>  
>  That's absolutly bogus nonsense.
>  
>  Some 90% of the sources are _text_files_.  (10% or whatever are graphics.)
>  
>  A text file is a text file is a text file.
>  
>  CVS knows the difference [for a reason].
>  
>  If I'm on a 390, I have a bunch of ebcdic files.  So what?  They are text.
>  They don't go into a repository as binary, unless they have some really 
> bizzare
>  formatting or escapes in them.
>  
>  I'm fixing my lineends.pl file that will cleanly translate the line 
endings 
> on
>  a unix or dos machine into unix or dos.  Then anyone can use zip on unix 
to 
> create
>  the win32 image.  The only hangup?  Perl's utime isn't doing what I 
expected 
> on
>  Unix, so it's touch'ing the date stamps when I coded it not to.
>  
>  There will be no binary .dsp or .dsw files in cvs.  ever.
>  
>  Bill

Mime
View raw message