B Smith-Mannschott wrote on Fri, 27 Mar 2009 at 21:43 +0100:
> 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
>
(using a maintainer-mode build?)
> 1. It is possible unknowingly commit a value for svn:ignore which
> mixes eol-style, using a version of Subclipse on Windows.
>
Possibly, but only with pre-1.6 servers.
> 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).
>
I believe you, but you wouldn't be able to create such a property (on
a 1.6 server) without using 'svnadmin load'.
> - 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.
>
Correct, 'load' applies less validity checks.
(However, some checks even 'load' doesn't skip: e.g., r33148.)
> # 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.
Yeah, ouch. It usually happened with svn:log so far, which are
unversioned.
> I have no way of preventing this from occuring again since the server
> doesn't protect itself against misbehaving clients.
>
You do. You can use hooks, or you can upgrade the server to 1.6
(which is the version in which the "protection against misbehaving
clients" was implemented).
> # 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.
>
Yeah, using a 1.5 server in the mirror (you *can* use svnsync 1.6, as
long as the mirror runs a 1.5 server) is a workaround.
> # 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.
>
The whole issue is that we're implementing #3 --- and that the way
svnsync works means it re-applies validity checks.
> Has anyone else seen this issue?
Yes, several, with svn:log.
> Is a fix likely?
> What can I do to help?
>
You can look into a way to normalize the EOL in those properties (e.g.: if
you see "foo\r\nbar\n", lie and say you saw "foo\nbar\n"). This could be
done in svnsync (it already implements some optional transforms as it does
the sync) or at the dumpfiles layer (the reader/writer of the dump will
optionally lie about the data it sees).
The error message gives the location of the code doing the validity
checking.
Daniel
> // 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].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1452196
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-28 22:33:23 CET