Re: svnsync and large property changes

Adriaan de Groot wrote:
> r.951943 changes a (long) property as part of a svk merge; it changes no files
> and seems to touch only one directory:
> r951943 | winterz | 2009-04-10 18:28:49 +0200 (Fri, 10 Apr 2009) | 8 lines
> Changed paths:
> M /branches/kdepim/enterprise4/kdepim
> Blocked revisions 951934 via svnmerge

[...]

> The regular svn client has no issues updating from r.951942 to 951943; only
> svnsync hits a problem.
>
> Does this seem familiar to anyone? None of the svnsync bugs that have been
> files seem to apply, and searching for the specific error message didn't turn
> up anything (now it shows my blog entry describing how I worked around the
> problem). I can provide the revs/ and revprops/ files for some of the
> revisions around the problem one, if that would help anyone. It'll be a while
> before I've re-created the problem situation, though -- running svnsync for
> the whole repo and for only the problem branch, to see if that makes any
> difference.

Adriaan, this is the second time in a week that I've heard about this kind
of problem. So, thanks to you, I can't call the other report a fluke. :-)

In the first report, the reason for the XML bogosity was due to the base64'd
property contents being truncated. The reporter seemed to think there was a
buffer overflow in an underlying APR routine. I found it very odd that
updates and checkouts with large property values seemed to work fine, but
not svnsync. I was never able to reproduce the problem myself, either.

I did notice, though, a subtle difference in the way these operations stream
the property values across the wire. I'm attaching a patch in this mail
which makes the code that svnsync uses a bit more like what is used for
regular updates. But it's a server-side change -- you'd have to convince
the KDE folks to give this a shot. If you can do that, though, I would
*love* to hear if it helps things. If it does, we can not only patch
Subversion to avoid this problem, but we'll also know better now to talk to
the APR folks about what might be a real problem in their codebase.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1748447

Index: subversion/mod_dav_svn/reports/replay.c
===================================================================
--- subversion/mod_dav_svn/reports/replay.c (revision 37276)
+++ subversion/mod_dav_svn/reports/replay.c (working copy)
@@ -152,10 +152,13 @@
     {
       const svn_string_t *enc_value = svn_base64_encode_string(value, pool);
 
- SVN_ERR(dav_svn__send_xml
- (eb->bb, eb->output,
- "<S:change-%s-prop name=\"%s\">%s</S:change-%s-prop>" DEBUG_CR,
- file_or_dir, qname, enc_value->data, file_or_dir));
+ SVN_ERR(dav_svn__send_xml(eb->bb, eb->output,
+ "<S:change-%s-prop name=\"%s\">",
+ file_or_dir, qname));
+ SVN_ERR(dav_svn__send_xml(eb->bb, eb->output, "%s", enc_value->data));
+ SVN_ERR(dav_svn__send_xml(eb->bb, eb->output,
+ "</S:change-%s-prop>" DEBUG_CR,
+ file_or_dir));
     }
   else
     {