[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: special property for text types

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Wed, 20 Feb 2008 17:25:30 +0100

On 2/19/08, Travis P <svn_at_castle.fastmail.fm> wrote:
> 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.)

I'm not sure which version incorporates the changes, but we used to
translate EOL style from one disk-file to another and than run over
the file again, comparing them. This has changed: we now don't need to
create another file, instead we translate in-memory and compare the
files from memory.



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-20 17:25:43 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.