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
1.6.2.
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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1480677
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-30 12:54:50 CEST