Re: [dev] application/octet-stream files in SVN repository
Hi Rich, On Tuesday, 2008-10-28 10:58:07 +0200, Rich wrote: just rambling here... wouldn't 'svn:eol-type native' make the most sense ? Usually not, it gives headaches with diffs created on, for example, a CrLf system that may not apply as patch on a Lf-only system, or vice versa, or if they do may result in mixed files, which would be even worse. Reasonably modern tools and editors are able to work with Lf-only files, so there is no need for native EOLs. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. pgp1ES4kRVipn.pgp Description: PGP signature
Re: [dev] application/octet-stream files in SVN repository
On 10/27/08 20:03, Jens-Heiner Rechtien wrote: Either these files were flagged as binary files in CVS or the Subversion import file type detection heuristic didn't work, so SVN choosed the save way (import the file as binary). The mime type can be changed, text would be best for the patches and in addition the svn:eolstyle should be set to CRLF. http://www.openoffice.org/issues/show_bug.cgi?id=95525 -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] application/octet-stream files in SVN repository
On 2008.10.27. 21:03, Jens-Heiner Rechtien wrote: Stephan Bergmann wrote: svn propget svn:mime-type --depth files svn://svn.services.openoffice.org/ooo/trunk/[EMAIL PROTECTED] shows that all of STLport-4.0.patch STLport-4.5-0119.patch STLport-4.5.patch dos_lineends.patch win32_custom.sh win32_sdk.sh are classified as application/octet-stream (and so, e.g., svn diff on them will not report anything useful). All of them consistently use LF line ends, except for dos_lineends.path, which consistently uses CRLF line ends. Why are all those files, erroneously in my opinion, classified as application/octet-stream? Either these files were flagged as binary files in CVS or the Subversion import file type detection heuristic didn't work, so SVN choosed the save way (import the file as binary). The mime type can be changed, text would be best for the patches and in addition the svn:eolstyle should be set to CRLF. just rambling here... wouldn't 'svn:eol-type native' make the most sense ? Heiner -- Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] application/octet-stream files in SVN repository
svn propget svn:mime-type --depth files svn://svn.services.openoffice.org/ooo/trunk/[EMAIL PROTECTED] shows that all of STLport-4.0.patch STLport-4.5-0119.patch STLport-4.5.patch dos_lineends.patch win32_custom.sh win32_sdk.sh are classified as application/octet-stream (and so, e.g., svn diff on them will not report anything useful). All of them consistently use LF line ends, except for dos_lineends.path, which consistently uses CRLF line ends. Why are all those files, erroneously in my opinion, classified as application/octet-stream? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] application/octet-stream files in SVN repository
Stephan Bergmann wrote: svn propget svn:mime-type --depth files svn://svn.services.openoffice.org/ooo/trunk/[EMAIL PROTECTED] shows that all of STLport-4.0.patch STLport-4.5-0119.patch STLport-4.5.patch dos_lineends.patch win32_custom.sh win32_sdk.sh are classified as application/octet-stream (and so, e.g., svn diff on them will not report anything useful). All of them consistently use LF line ends, except for dos_lineends.path, which consistently uses CRLF line ends. Why are all those files, erroneously in my opinion, classified as application/octet-stream? Either these files were flagged as binary files in CVS or the Subversion import file type detection heuristic didn't work, so SVN choosed the save way (import the file as binary). The mime type can be changed, text would be best for the patches and in addition the svn:eolstyle should be set to CRLF. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
