On Apr 1, 2005, at 6:43 AM, Trent Apted wrote:
>> Media types do not define the encoding, only the type of the
>> contents. Therefore we a) can't extrapolate eol-style from the mime
>> type, and b) would be totally wrong to do so because there are valid
>> reasons _not_ to use native eol-style even in mixed-platform
>> environments.
>
> 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.
Your imagination hasn't been watching the dev@ list. :-)
Here's a reason why svn:eol-style=native should not be tied to anything:
http://svn.haxx.se/dev/archive-2005-03/1072.shtml
I give users a huge (measured 10x) performance boost on WC operations
where the WC is on a network share (AFS) by not allowing svn:eol-style
or svn:keywords properties on source files in the repositories I admin.
(A precommit hook enforces only LF line endings and no svn:eol-style
or svn:keywords properties allowed.)
We generally aren't cross-platform (all Unixy: AIX, Linux, MacOS X),
but if anyone does editing on Windows, they'll have to find an editor
or other way to use only LF line endings. This trade-off is a huge win
for us because the AFS WC operations on Unix are very much "the common
case" for us.
> 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++.
That's a pretty rough heuristic. So, if all C and C++ start with the
same /* copyright notice, the detection system assumes all the C++
files are C, and ignores the filename extension?
> Perhaps my annoyance with having to specify a native eol-style each
> time I add a new source file
As someone else mentioned, it sounds like you haven't discovered the
[auto-props] in your config file which can be set to automatically add
svn:eol-style=native to files in very many cases and will likely
eliminate your trouble.
Cheers,
Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 1 21:59:34 2005