Re: svnsync and large property changes

C. Michael Pilato wrote:
> C. Michael Pilato wrote:
>> 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.
>
> For more on this issue (including a commit to APR which fixes it), see
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&viewType=browseAll&dsMessageId=1897250
>
> TODO: File a Subversion issue about the problem, noting the fix in APR, but
> devising a workaround for folks that can't easily get a new APR release. I
> suspect this will have a little something to do with not using
> apr_brigade_vprintf() at all for the large property values, but using
> apr_brigade_write() directly instead.

Okay, I never got around to filing the issue, but the APR fix is done, and
now trunk uses the workaround of _write() instead of _vprintf() for the
large base64 property block now (with a backport recommended for 1.6.x).

-- 
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=2097669