Trent Apted wrote:
> a) I'm not convinced that we can't determine an eol-style because we
> only know the type of contents, and b) I can't think of any reason why
> I would want my source code in something other than the native format
> for whatever platform I'm editing it on.
I'm working on a project this very minute where the customer requires
all files to have CRLF line endings, even though the project is
cross-platform.
>>
>> *ROTFL*
>>
>> Oh and surely it would not be platform specific at all, aye. It would
>> work on *every* Linux box in the world (well, except some older ones).
>
>
> Don't be silly. This is a plaintext file. Last I checked text files
> were readable on my non-Linux computers -- Windows isn't that bad.
Sorry, the way I understood it you implied that /usr/bin/file was not
platform-specific.
> Sarcasm aside, the point is the way in which the mime type is
> determined, which I had hoped would be evident in my choice of
> quotation. Reading the first N bytes of a file and matching them to a
> known sequence (which could be in a file distributed with Subversion
> or statically linked via source automatically generated from the above
> file) is in no way platform dependent. Obviously this is not a
> complete solution, but it gets most of the way there.
When I said platform-specific implementation I meant just that. On
Windows, there are native APIs that will a) guess or b) look in the
registry to find a file's MIME type. I've also heard of a system (can't
recall the name, but it's not Mac OS) where the file type is recorded as
a property of the file in the filesystem, and so of course we'd want to
use that information.
> Perhaps my annoyance with having to specify a native eol-style each
> time I add a new source file is testament to the fact that I am
> knowledgeable about what it means for something to be platform
> dependent, having been a developer of cross-platform software projects
> for some time now.
Then I'm sure you know the difference between "portable" and
"platform-specific". Subversion aims to be portable by using
platform-specific tools. That's certainly one reason why we're using APR
for our portability layer.
>>>
>>> I can write a patch, if you like.. PhD students tend to find time
>>> for all kinds of non-thesis pursuits ;-)
>>
>>
>>
>> Any change in this direction must be generic in the sense that it
>> allows platform-specfic implementations, and it must produce portable
>> results. I will veto any patch that produces MIME types that are not
>> in the IANA registry.
>>
> Actually, looking further it appears that the heuristic for c/c++
> files is that if a file starts with "/*" it is C, and if with "//" it
> is C++. `0xbabe` is a Java class file, etc.
> Maybe I'll just work on that patch, despite your discouragement, and
> see if I can make you happy.
That wasn't meant to be discouraging. On the contrary, I think such a
patch would be a good thing. I'm simply telling you how the patch must
behave in order to be acceptable (to me). And I'm not laying down
arbitrary rules; I'm just interpreting the rules we already have in the
context of this particular feature.
When I say the solution must allow platform-specific implementations, of
course I don't mean that *your* patch must contain implementations for
all platforms. But the framework should be there. Others can fill in the
blanks on other systems.
As for using IANA's registry as the reference: there are many
non-standard MIME types being used, some with fairly common meanings
(e.g., application/x-gzip-compressed), and some that are more obscure
(e.g., image/x-bmp). So, perhaps limiting ourselves to the registered
types is a bit restrictive, but it's a safe baseline.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 1 16:32:00 2005