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

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

I've discovered a regression in 1.6.0 relating the following error message:

    .../1.6.0/subversion/libsvn_repos/fs-wrap.c:189: (apr_err=125005)
    svnsync: Cannot accept non-LF line endings in 'svn:ignore' property

1. It is possible unknowingly commit a value for svn:ignore which
   mixes eol-style, using a version of Subclipse on Windows.

2. The presence of this property value effectively breaks svnsnync
   1.6.0 because it insists on eol-style purity.

# Reproduction

I have constructed a minimal dump file to reproduce this
issue. Revision 1 defines an svn:ignore on / containing a CR (^M).

- This dump file can be successfully loaded into a fresh repository
  using either svnadmin 1.5.2 or svnadmin 1.6.0.

- svnsync 1.5.2 will successfully sync revision 1 to a clone
  repository.

- svnsync 1.6.0 fails to sync revision 1.

    .../1.6.0/subversion/libsvn_repos/fs-wrap.c:189: (apr_err=125005)
    svnsync: Cannot accept non-LF line endings in 'svn:ignore' property

It appears that svnadmin load 1.6.0 is not as strict as svnsync
1.6.0.

# Problem

I now have a 1.6 GB repository which I no longer able to back up using
svnsync. Correcting the problem would mean dumping, editing the huge
dump file and reloading the repository. I have no way of preventing
this from occuring again since the server doesn't protect itself
against misbehaving clients.

# Story

I have a colleague using Rational Application Developer (an Eclipse
dirivative) with some as yet undetermined version of Subclipse,
running on Windows XP. Today he added an entry to the svn:ignores
property one directory in our 1.6 GB repository.

The new value for svn:ignores apparently had mixed
eol-conventions. Recall that this user's platform uses CR/LF -- it's
Windows. You may protest, rightly, that Subclipse *should* be using
only LF to terminate lines of textual svn: properties. But fact is:
it gladly mixes the LFs that are already there with CRLF for new
additions. *What's worse: the subversion server accepts this commit
without protest*

(The server is still on 1.4.x, running on Solaris. I have no direct
access to that box.)

So, now I have a repository containing a bad svn:ignore.

I maintain an offsite clone of our central repositories using svnsync
to clones on my work machine. This works fine with svnsync 1.5.x
(1.5.2, specifically) even in the presence of this broken svn:ignore
property.

I upgraded my personal machine (the one holding the clone
repositories) to 1.6.0 today and discovered this problem
coincidentally. It appears that I will have to roll back the update
and stay on 1.5.x until 1.6.0 becomes more tolerant.

# Query

This isn't the first time I've run into something like this. (I recall
similar problems with RAD+Subclipse+Windows a year or two ago relating
to svn:externals.)

Why is subversion so anal-retentive about eol-style purity in its own
properties? SVN clearly knows these properties are textual, so I see
three alternatives:

1. Subversion could be more tolerant of eol-style when reading these
   properties without losing information.

2. Alternatively, it could normalize the eol-style when these
   properties are written.

3. Failing all that, it could at least refuse to accept values using
   an impure eol-style. It already does this for files judged textual.

Has anyone else seen this issue?
Is a fix likely?
What can I do to help?

// ben

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1448375

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].