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

Re: svnsync 1.6.0 fails to sync repositories with ^M in an svn:ignore

From: B Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Mon, 30 Mar 2009 12:54:03 +0200

On Mon, Mar 30, 2009 at 10:53, B Smith-Mannschott <bsmith.occs_at_gmail.com> wrote:
> On Mon, Mar 30, 2009 at 09:54, B Smith-Mannschott <bsmith.occs_at_gmail.com> wrote:
>> It appears my fix is only partial. Revision properties also need to be
>> sanitized:
>>    svnsync: Cannot accept non-LF line endings in 'svn:log' property
>> Crud. Time to fire up emacs. Oh, never mind, my emacs is always running. ;-)
>> // Ben
> Upon further investigation, this problem is worse than I anticipated.
> I believe it will derail our plan to upgrade our servers to 1.6.
> (We're still on 1.4.x and the lack of merge tracking is a real
> hindrance.):
> The developer who made the commit including ^M in its log message is running:
> Rational Application Developer 7.5.1 (~ Eclipse 3.4.1)
> Subclipse 1.4.7 (using JavaHL 1.5.5)
> I had him update his Subclipse to 1.6.x (which is based on Subversion
> 1.6.0), but this *made* *no* *difference*. Log messages still come
> like this:
>    test^M
>    comment^M
>    for^M
>    svn^M
>    linebreak
> This means that were we to upgrade our servers to 1.6.0 *today*, 90%
> of the developers on my team (I'm the only one using Linux) would be
> unable to commit to the repository because the server would refuse
> their log comments for lack of eol-purity. And what's worse, not even
> updating to the most recent version our Subversion client will help.
> I don't imagine that this was the intended consequence of making
> subversion stricter about its internal properties. Perhaps it would be
> smarter to make it more liberal in what it accepts and have it
> normalize these properties -- on the server side -- before committing
> them to disk.
> I'm perfectly willing to hack up my personal copy of svnsync to make
> it work around these problems, but I'm not able or willing to do this
> to the svn we'll be running on our central servers.

I have since been able to reproduce this using plain Eclipse 3.4.1 (no
RAD required) under Windows with both Subclipse 1.4.8 *and* Subclipse

In the process, I have discovered a work-around, of a sort.

(1) check out a project form a repository hosted on svnserve 1.6.0
(2) make local changes
(3) commit
(4) enter a commit message of at least two lines length
(5) commit
=> 'SVN Commit' has encountered a problem.
org.tigris.subversion.javahl.ClientException: Wrong or unexpected property value
svn: Commit failed (details follow):
svn: Cannot accept non-LF line endings in 'svn:log' property.
=> commit failed.
(6) commit (again)
(7) select the previously entered commit message form <Choose a
previously entered comment>
=> Commit succeeds.
=> It appears that entry into and retrieval from commit log history
normalizes line-breaks implicitly.

IMHO this is something that should be fixed once in core, rather than
N times in all the various clients.

> Suggestions for course of action?

// Ben


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-30 12:54:50 CEST

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.