Introduction
============
I've discovered a cluster of problems caused by the decision to be
stricter about eol-style in the values of `svn:*` properties in
subversion 1.6.
You'll find relevant threads on the users lists for [subversion][1] and
[subclipse][2].
[1]: http://tinyurl.com/cxu389
[2]: http://svn.haxx.se/subusers/archive-2009-03/0095.shtml
Facts
=====
1. Subversion 1.6 no longer accepts carriage returns (^M) in the
values of its own properties (i.e. `svn:log`, `svn:ignore` and
others). Prior to 1.6 such properties were accepted.
2. `svnadmin load` does not normalize the eol-style of `svn:` properties
during loading.
3. Subclipse (all versions, including those based on Subversion 1.6),
when running on Windows will happily insert carriage returns into
these properties when it manipulates them. (TortoiseSVN on Windows
does not make this mistake, though other clients may.) [3]
[3]: http://tinyurl.com/cfwy9p
Consequences
============
1. `svnsync` 1.6 fails when the source repository violates eol-purity
on any of the relevant properties.
Due to the popularity of Eclipse and Windows a large number of such
repositories must exist in the wild.
A dump/load cycle will not help here because svnadmin load accepts
the impure property values as they are.
2. Commits to 1.6 repositories by Eclipse users on Windows are
essentially impossible. (If they never use `svn:ignore` or
`svn:externals` and only write one-line commit messages, they might
get away with it.)
There is a clutzy workaround for this, see [3].
[3]: http://tinyurl.com/cfwy9p
It seems to me that this could be construed as breaking Subversion's
stated goals of backwards compatibility in the 1.x series.
Progress (not much)
===================
I first discovered the problem in connection with `svnsync` and
`svn:ignore`. You'll find a patch which addresses this specific problem
[4], though it is incomplete [5] and buggy, as helpfully pointed out
by Daniel Shahaf [6].
[4]: http://tinyurl.com/cvyte7
[5]: http://tinyurl.com/c92e2n
[6]: http://tinyurl.com/dayvpe
I've also begun digging into the [code for Subclipse][7], though I
haven't groked it deeply enough to identify the optimal place to
implement a fix from that end. (Such a fix would only address
consequence 2.)
[7]: http://subclipse.tigris.org/source/browse/subclipse/trunk/
Options, that I can see
=======================
Subversion should be more tolerant in what it accepts
-----------------------------------------------------
My initial reaction was that this ought to be "fixed" on the
subversion side by having the repository, which is accepting the
property values normalize them before writing them to disk.
This, however, would seem akin to a hook script which alters the
in-progress transaction. This, as I recall is verboten in Subversion
because there's no provision to have the server tell the client, after
the commit, that some things were not committed exactly as sent.
I do wonder if this would be such a problem. I can see real confusion
with file contents in the face of update or merge, but subversion
never does textual merge on the contents of properties, does it?
Clients should be Fixed and svnadmin load should correct
--------------------------------------------------------
The other option, I see is to have svn 1.6 remain as it is, while
teaching svnadmin load to understand
--normalize-svn-property-eol-style so that old commits don't kill
svnsync. (alternately teach this to svndumpfilter).
Syncing repositories not so cleaned up would still requrie changes
to svnsync akin to what I've begun in my patch.
Finally, going this route would require that all clients be careful to
do eol-normalization on their side before passing property values on
to the svn libraries.
This won't be a fix for users who can't upgrade to the latest version
e.g. Subclipse because they are stuck on some old Eclipse. (This
isn't so much a problem for those using only Eclipse, but it may be
for those using older versions of commercial products built on
Eclipse, like IBM's craptastic RAD.)
What Next?
==========
I'm willing to continue hacking on my svnsync patch, though I'm almost
certainly not the correct person for this job. The last time I used C
was 10 years ago and I'm woefully unversed in Subversion's APIs.
It seems that a patch for Subclipse will certainly be required. Here,
I'm more likely to make progress as I've been hacking in Java since
2001.
Thanks
// Ben
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1493120
Received on 2009-03-31 10:12:03 CEST