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

Re: converting from SVN to CVS

From: David Weintraub <qazwart_at_gmail.com>
Date: Wed, 28 Jan 2009 12:45:03 -0500

On Wed, Jan 28, 2009 at 10:33 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> It would be nice to be able to configure the server to say "If a file
>> ends in these suffixes, it is a text file, store the file with Unix
>> line endings and if you see a lone CR, a CRLF, or a LF, convert it to
>> LF. Then, when the client checks out the file, it would convert the
>> Unix line endings to whatever it wants.
> That's pretty much how it works. But, it doesn't use file names.
> Basically if you don't set a mime type svn assumes it is a text file.
> Also, svn always stores text files with LF as the only line ending. From
> the svn book:

The first link you sent me has this to say:

Unless otherwise noted using a versioned file's svn:mime-type
property, Subversion assumes the file contains human-readable data.
Generally speaking, Subversion uses this knowledge only to determine
whether contextual difference reports for that file are possible.
Otherwise, to Subversion, bytes are bytes.

This means that by default, Subversion doesn't pay any attention to
the type of end-of-line (EOL) markers used in your files.

I always assumed that meant that Subversion simply doesn't care. You
put LF on the end, it stores them that way. If you put CRLF, it stores
them that way. Otherwise, why do we keep running into files with both
line endings on them all the time?

What I'd really like to see is Subversion act if all text files have
svn:eol-style:native on by default, and either refuse to commit files
with mixed EOLs (as it does now) or fix them.

David Weintraub
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-28 18:45:59 CET

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

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