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

Re: Why not repair native svn:eol-style?

From: William Uther <will+_at_cs.cmu.edu>
Date: 2002-08-03 23:14:46 CEST

On 2/8/02 7:03 PM, "Blair Zajac" <blair@orcaware.com> wrote:

> Greg Hudson wrote:
>> On Thu, 2002-08-01 at 23:49, Blair Zajac wrote:
>>> Why isn't this done for the native style? I don't see any need for it.
>> If the repair flag is not set, the EOL translation is a reversible
>> transformation; if you accidentally commit a binary file with
>> svn:eol-style=native, then you can get the original contents back by
>> checking it out again on the same platform.
>> However, if the repair flag is set, the EOL translation is
>> data-destroying.
>> When we discussed this before (see the list archives--long thread,
>> though), we were concerned about accidentally destroying data when
>> svn:eol-style=native, but felt that fixed eol-styles were specialized
>> enough that they were very unlikely to accidentally appear on binary
>> files.
> Well, it's in the tree now in rev 2864.
> I think we should look at the problems people are actually seeing. There
> was one problem with a checkin this week on RapidSVN and problems I've been
> having at work (we are now using svn!!!) where people are doing commits of
> mixed eol text files.

I like the non-data-destroying guarantee. Maybe have --force fix the line
endings? And a note in the error to use --force to override?


\x/ill :-}

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 4 01:17:04 2002

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.