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

Re: Another EOL Proposal

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2001-12-14 20:34:48 CET

On Fri, 2001-12-14 at 14:27, Sander Striker wrote:
> I know, another proposal. This probably overlaps
> with the other proposals in a major way, but I
> just want to get this off of my chest.

I disagree with this proposal because:

  1. It doesn't deal with .DSP files. (If you set "eol" to "CRLF", the
file will have CRLFs in the repository, but not on checkout on a Unix
platform. If you set "eol" to "none", you get the situation we have
now, which we don't consider acceptable.)

  2. It's mostly pointless to allow the user to force three different
possible styles of newline in the repository, when they're all just
going to be converted to the native format on checkout anyway. (Only
"mostly pointless" because there are other access paths, but I can't
imagine a situation where it would be beneficial to set the repository
newline style to CRLF and still have Subversion checkouts on Unix
convert those to LFs.) Better to define a single, global, natural
newline style for the repository.

> - <non-existent>
> If the property doesn't exist, check the parent
> directory for this property. If that isn't set,
> bubble up further. If the property is non existent
> the entire path up to the root in the repos, default
> to "none".

Another way to handle this is to make the client inherit the property
from the parent directory when it creates a new file or directory, and
to provide a recursive "svn propset" for converting existing stuff.
But, really, this is a topic for the future. Doing bubble-up checks or
property inheritance right now is probably too much work.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006

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.