Revprops are the easy part (they can be fixed in-place, without even
svnsync). All the clients out there that suddenly get their line-endings
rejected are the bigger problem of the two.
Anyway, I think you'll get more useful responses on dev@. Feel free to
summarize the thread there. :-)
Thanks.
Daniel
(I already CCed them on an earlier mail.)
B Smith-Mannschott wrote on Mon, 30 Mar 2009 at 12:54 +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
> 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].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1485628
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-30 22:20:00 CEST