[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r966822 - in /subversion/trunk/subversion: libsvn_client/repos_diff.c tests/cmdline/merge_tests.py

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 3 Aug 2010 12:40:58 -0400

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

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

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


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.

Received on 2010-08-03 18:41:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.