Inconsistent Line Ending Style

[dan-fl]

We're trying to convert our repository from PVCS on Windows to Subversion on Windows, and we're seeing "Inconsistent line ending style" error with only the initial revision of binary files. All other revisions of binary files seem to be just fine.



Any idea what might be going on here, or where we can look to fix it?

Thanks in advance,
dan

[kencorbin]

I think we need more info...

Obviously you running something subversion now on a post migration, and subversion is unhappy about something. A quick Google search for that error string finds a lot of hits describing all kinds of unusual situations, we need to figure out just which one applies to you.

Question 1, what exactly are you doing when Tortoise SVN generates that error? Trying to check out a file, just browse it, make a commit, or something else?

Could you check the setting of the subversion properties for the revisions you are having trouble with. In particular, what are the settings of svn:mime-type and svn:eol-style?

[dan-fl]

The process I use in TortoiseSVN to generate the error message is:

For binary files with only one revision: right-click, open
For binary files with multiple revisions: right-click, properties, select the initial revision, right-click, open

For instance, I pick a random jpeg file in my converted repo:

Properties for the file:
svn:eol-style = CRLF
svn:mime-type = image/jpeg
svn:needs-lock = yes

Here is a file properties comparison. You can see that the SVN version is larger:
http://tinypic.com/r/10gld1j/5

Here is a binary comparison of the same file:
http://tinypic.com/r/qysv9c/5

Other file types:
Java jar files have:
svn:eol-style = CRLF
no mime type

Excel files have:
svn:eol-style = CRLF
svn:mime-type = application/vnd.ms-excel
svn:needs-lock = yes

MS Word files:
svn:eol-style = CRLF
svn:mime-type = application/msword
svn:needs-lock = yes

All of them exhibit the same behavior.

===========================================================
Change History

Archive: ~~~~~~\Images\magplus.png-arc
Workfile: magplus.png
Archive created: Sep 14 2006 09:43:16
Split mode: Unsplit
Owner: cro
Last trunk rev: 1.0
Locks:
dtrevino : 1.0 for 1.1 (DEV)
Checked Out to: H:\PVCSWORK\Finance\Images\magplus.png
Groups: PRD : 1.0
DEV : 1.0
Rev count: 1
Attributes:
WRITEPROTECT
CHECKLOCK
NOEXCLUSIVELOCK
NOEXPANDKEYWORDS
NOTRANSLATE
NOCOMPRESSDELTA
NOCOMPRESSWORKIMAGE
NOGENERATEDELTA
COMMENTPREFIX = ""
NEWLINE = "\r\n"
Version labels:
"Request 102203" = 1.0
"TST 20060915/135703" = 1.0
"QAT 20060915/135803" = 1.0
"PRD 20060929/151718" = 1.0
Description:
102203 Google Tool Kit image files used to generate document viewer for fax imaging project

-----------------------------------
Rev 1.0
Locked by: dtrevino
Checked in: Sep 14 2006 09:43:16
Last modified: Aug 15 2006 12:56:28
Author id: cro lines deleted/added/moved: 0/0/0
Initial revision.
===================================

[kencorbin]

I think the culprit is the
svn:eol-style=CRLF
property. I would have thought that seting would be ignored for binary files, but apparently is not the case.

How that and the svn:need-lock properties are getting set is a mystery. A quick search of the importer source didn't find any way to set or default those properties. But there configuration settings in Subversion that will do that. My guess is that you them set.

As a quick confirmation of that guess, could you look at the dump files and see if the string "svn:eol-style" appears anywhere in there. If they are getting set in the dump file you will see something that looks like

K 14
svn:eol-style
V 4
CRLF

If you do not find any such thing, that would confirm my suspicions, and you should look at your subversion settings. On a linux system you would find these in a .subversion directory off the home directory in a file named config. I'm not sure where they are on a Windows system. You can look that up in the manual. Once you find it, see if there is an [auto-props] section and if enabl-auto-props is set to yes.

Good luck,
-Ken

[dan-fl]

Acutally, this is a snippet from one of the dump files showing EOL style in the dump. Is this coming from PVCS or the dump process?

Thanks Ken.

==========================================
Node-path: trunk/Test1/amgl1000.rpt
Node-kind: file
Node-action: add
Prop-content-length: 113
Text-content-length: 134656
Text-content-md5: 0e9642baed58984698b160eb096a30d4
Content-length: 134769

K 18
PVCSRevisionNumber
V 3
1.0
K 11
description
V 20
44342 - Initial load
K 13
svn:eol-style
V 4
CRLF
PROPS-END

[kencorbin]

Well, that is definitely coming from the dump process, which blows that theory.

One last possibility, there is a autoprops.config file that controls which property settings are applied to files with specific prefixes. Is that set to apply svn:eol-style settings to things that it shouldn't???
Good luck,
-Ken