Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c

[An update on my thinking here.]

I have a patch in which svnrdump hard-codes an override of the runtime
configuration to set two things:

   http-max-connections = 2
   http-bulk-updates = TRUE

The bulk updates thing will fix the known problems for servers which allow
them (which really ought to be most live servers). If the server says,
"Sorry, no bulk updates", then the idea is that limiting ra_serf to a single
aux connections will do the trick.

Unfortunately, it doesn't do the trick right now, because even ensuring that
all the GETs/PROPFINDs come down in the right order does not a well-ordered
editor drive make. Because ra_serf still only closes directories
opportunistically, it could process GETs for files across multiple subdirs
before ever taking a moment to pause and see what needs to be cleaned up.

That's not to say that improvements in svnrdump itself can't work around
these remaining ordering problems. Someone (I think it was Bert...)
recently changed svnrdump to actually use separate file and directory and
editor batons, which was definitely a step in the right direction. And I
believe there is still some separation which could be done, so maybe
finishing that work gets us to where we need to be. So, I'm not raising a
white flag -- I'm merely saying that right now I'm still observing
brokenness even when ra_serf is only using a single aux connection.

I'll return to debugging all this on Monday.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development