RE: Got error "Cannot accept non-LF line endings in 'svn:log' property

As I previously posted as a followup, the actual log message that caused
problems was "Got rid of ^M and tabs" with ^M being the actual control
character (no associated ^J after it)...

This is with svn --version:

svn, version 1.7.0 (dev build)
   compiled Mar 18 2011, 22:26:47

and modules ra_neon, ra_svn, ra_local.
-- 
Daniel


-----Original Message-----
From: Michael Haggerty [mailto:[email protected]] 
Sent: Friday, April 08, 2011 12:57 PM
To: Daniel Schepler
Cc: [email protected]; Jinsoo Kang
Subject: Re: Got error "Cannot accept non-LF line endings in 'svn:log'
property

On 04/08/2011 08:04 PM, Daniel Schepler wrote:
> I was trying a preliminary run of cvs2svn on my company's CVS 
> repository and got this error:
> 
> Starting Subversion r7624 / 65959
> ERROR: svnadmin failed with the following output while loading the
dumpfile:
> svnadmin: E125005: Invalid property value found in dumpstream; 
> consider repairing the source or using --bypass-prop-validation while
loading.
> svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' 
> property

That's the first time I've heard of this error message.  It seems
implausible that no CVS repository has ever had a CRLF-terminated log
message before.  I wonder whether it is a new feature of "svnadmin
import"?

> Is cvs2svn supposed to correct line endings on CVS log messages?  If 
> it's supposed to, how would I go about debugging why I'm getting that 
> error message?  If not, is there some way I could insert Python code 
> in the .options file to do the conversion?

No, cvs2svn hasn't concerned itself with fixing such a problem, but it
is pretty easy to do, so I just implemented this feature on the trunk
version of cvs2svn as r5338-5340.

Implementation note: The log message is processed in CleanMetadataPass
by being passed through

    clean_log_message = ctx.cvs_log_decoder(log_msg)

ctx.cvs_log_decoder is usually an instance of CVSTextDecoder, and it
used to be responsible only for converting the text from some unknown
encoding into Unicode.

I just added an option to allow it to canonicalize EOL strings as well
(by calling common.canonicalize_eol(log_msg, '\n') on the string after
it has been converted to Unicode).

Michael

--
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2718212

To unsubscribe from this discussion, e-mail: [[email protected]].