On Feb 7, 2008, at 3:19 PM, Christopher Key wrote:
> C. Michael Pilato wrote:
>> Karl Fogel wrote:
>>> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>>>> I like the thinking here, but would prefer to optimize this a bit,
>>>> perhaps by simply allowing svn:eol-style to accept a value which
>>>> means
>>>> "don't do any EOL conversion, but note that this is line-based".
>>>> maybe "*" or "" or something.
>>>
>>> I think the documentation for svn:is-text should recommend that the
>>> user seriously consider if they need to set svn:eol-style instead
>>> (after all, how often would you need to say something's text and yet
>>> not be willing to set svn:eol-style to at *least* "native"?),
>>> though.
>>
>> But you think having two properties won't cause the same sorts of
>> confusion? "Do I need to set svn:is-text?" Or, "This file had
>> svn:eol-style=CRLF but I need to remove that property; shoot, I
>> forgot to also add svn:is-text!". You're just begging for more of
>> a mess.
>>
>> I hear you about the so-called task breakdown, but that too runs
>> afoul of your suggestion to satisfy the "task" of diffing/merging
>> by even consulting svn:eol-style (which is allegedly unrelated to
>> this "task"). My point is simply that we can (and should) *make*
>> svn:eol-style related to this task, too, and can do so without
>> disturbing its other currently assigned task.
>>
> It strikes me that the an svn:is_text property is essentially
> redundant. If a file is truly line based, then surely by
> definition it has consistent line endings throughout, and I can see
> no reason not to set the svn:eol-style property for that file. If
> a user has a file where they want to preserve the different line
> endings throughout, then it really isn't a line based file, and
> line based operations are no longer appropriate; they won't show
> changes in line endings correctly, something they've already
> asserted they're interested in by not setting svn:eol-style. I
> really can't see any excaptions to this.
I see lots of people making the assumption that it's harmless to set
svn:eol-style on text files. That has not been my experience.
However, in an environment with many people having working
directories on a non-local filesystem, such as AFS, the extra
processing that is caused by line-ending-normalization is dramatic
and horrid. And in our environment, it isn't adding anything because
no one is access the repos on Windows.
So, to save all users daily pain, I've removed the svn:eol-style from
all the source files. All users use Un*x systems (AIX, Linux, MacOS
X) to access the repository and I've added a hook script to ensure
that no Windows-style line-endings make it into the repos by mistake.
I need text files to continue to be recognized for line-based diff,
merge, etc. without the stiff performance penalty triggered by
setting svn:eol-style.
(Caveat to my argument: I haven't tried adding svn:eol-style back
recently to test if some advance was made in recent releases that
might minimize the penalty. I believe the penalty was because
Subversion was creating tmp files in the .svn/ directories in AFS
working copies for every source file so it could normalize endings
for comparison and other operations.)
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-19 23:32:51 CET