Ok, I am waving the white flag as far as implementing a fix for issue
#3657 in the RA layer. I simply don't see how it can be done outside
of this: Put the DAV update report handler into send-all=TRUE
<S:update-report send-all=TRUE> mode when creating a
svn_ra_reporter3_t * during a merge/diff. This would prevent
<S:fetch-props/> response that causes the client to fetch *all* the
properties of a path which subsequently pushes these to the
svn_delta_editor_t callbacks as if they were all prop *changes* (as
Mike discussed here
http://subversion.tigris.org/issues/show_bug.cgi?id=3657#desc9).
fyi: Currently this is how the two DAV RA layers use send-all mode:
send-all send-all
mode mode
operation ra_serf ra_neon
--------- -------- ---------
update FALSE TRUE
status FALSE TRUE
switch FALSE TRUE
diff FALSE FALSE
In that attached patch I reverted r966822 and tried the aforementioned
approach by tweaking ra_neon so the send-all mode on diff/merge is
TRUE. The whole test suite passes (including the test for issue
#3657). I haven't got an equivalent change to ra_serf to work yet,
but I'm not too worried about that yet because...
...After testing out this idea, I realized the problem with this
approach: It reopens issue #2048 'Primary connection (of parallel
network connections used) in ra-dav diff/merge timeout
unnecessarily.':
http://subversion.tigris.org/issues/show_bug.cgi?id=2048
http://svn.apache.org/viewvc?view=revision&revision=853457
So I'm at a dead-end right now. I'm happy to revert r966822 and
reopen issue #3657 if the consensus is that my initial fix is a sloppy
band-aid to cover incorrect ra_neon/ra_serf behavior and that the
latter two are where the fix belongs.
Paul
