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

Re: Faulty line-end handling in "svnadmin load"? [was: Problem with eol-style=CRLF.]

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-08-20 18:25:08 CEST

Michael Haggerty wrote:
> On the cvs2svn mailing list, somebody wrote the message quoted below.
> He claims, basically, that if a file that has svn:eol-style=CRLF is
> written to a dump file with different line-end convention, then "svn
> diff" gets confused.
>
> I would appreciate guidance about where this should be fixed:
>
> 1. Is this a bug in "svnadmin load" (i.e., should it do the line-end
> conversion itself before storing the file text)?

No. 'svnadmin load' should never change anything, period. That would
merely mask bugs in the dumpfile generator.

> 2. Is this a bug in "svn diff"?

I don't think so.

> 3. Or is it indeed an intended requirement of "svnadmin load" that files
> be committed using the same line-end convention as specified in their
> svn:eol-style property (i.e., a cvs2svn bug)?

Yep.

Subversion has a concept of "repository normal format", which is defined to
be Unix-style line endings and contracted keywords.

Unlike CVS, where files are text unless explicitly declared binary (-kb),
Subversion does not assume that everyone wants "native" EOL style on all
files by default. So, IIRC:

  * files that don't have svn:eol-style set are stored as-is in the
    repository

  * files that have svn:eol-style set to a particular fixed format ("CRLF",
    "LF", etc) are stored in the repository in that format

  * files that have svn:eol-style set to "native" get stored in this
    repository normal format, and the client takes care of translating
    between RNF and the correct line ending style.

> -------- Original Message --------
> Subject: Problem with eol-style=CRLF.
> Date: Fri, 25 May 2007 23:32:29 -0400 (EDT)
> From: Bart Oldeman <bartoldeman@users.sourceforge.net>
> To: dev@cvs2svn.tigris.org
>
> Hi,
>
> I encountered the following issue converting a CVS repository where all
> text files have to be CRLF (FreeDOS):
>
> Used cvs2svn (1.5.0) on Linux, with DefaultEOLStyleSetter('CRLF') in the
> options file, conversion happened without problems.
>
> When checking out from the new SVN repository I noticed that all checked
> out files had CRLF line endings (correct), but as soon as I changed a file
> and 'svn diff'ed it reported that the whole file changed its line endings
> from LF to CRLF (not correct).
>
> The cause is that cvs2svn converts the text files to have LF line endings
> whereas subversion expects them to have CRLF line endings in the
> repository (only when eol-style is set to CRLF obviously).
>
> I worked around it by changing dumpfile_delegate.py to do
>
> if s_item.needs_eol_filter:
> data_reader = CRLF_EOL_Filter(LF_EOL_Filter(pipe.stdout))
> else:
> data_reader = pipe.stdout
>
> and
>
> class CRLF_EOL_Filter:
> """Filter a stream and convert all LF end-of-line markers
> into CRLFs."""
>
> def __init__(self, stream):
> self.stream = stream
> self.eof = False
>
> def read(self, size):
> while True:
> buf = self.stream.read(size)
> self.eof = len(buf) == 0
> buf = buf.replace('\n', '\r\n')
> if buf or self.eof:
> return buf
>
> this is just a quick workaround I could use for FreeDOS; a proper solution
> would also care about CR line endings and do the right thing.
>
> Bart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Mon Aug 20 18:22:52 2007

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.