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.
--
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=1897776
Received on 2009-04-24 23:09:21 CEST