On Feb 9, 2012 12:26 PM, "C. Michael Pilato" <cmpil...@collab.net> wrote: > > On 02/09/2012 11:41 AM, Philip Martin wrote: > > "C. Michael Pilato" <cmpil...@collab.net> writes: > > > >> On 02/09/2012 05:22 AM, Philip Martin wrote: > >>> Hyrum K Wright <hyrum.wri...@wandisco.com> writes: > >>> > >>>> Is there any sense of closure on the serf+windows test failure on the > >>>> 1.7.x branch? My sense is that the failure does *not* expose a new > >>>> bug on the branch, but rather smokes out an existing one. > >>> > >>> That's my view as well. svnrdump has a bug that causes it to rely on > >>> the server responding to serf's series HTTP requests in a particular > >>> order. It's not a new bug. > >> > >> Has that actually been established? I mean, if all svnrdump is doing is > >> expecting ra_serf to honor the well-established, well-documented, but > >> ra_serf-flaunting Ev1 editor drive ordering rules ... is that really > >> svnrdump's bug? > > > > svnrdump doesn't handle postfix text deltas. It doesn't handle the > > sequence open_file, open_file, ... close_file, close_file. I don't > > know whether it's the cause of this particular problem but the fact that > > we are seeing an ordering bug is not surprising. > > Bah. I'd be surprised if most of our editors supported postfix text deltas. > To my knowledge, there is exactly one driver which uses that approach in > our own codebase (the commit driver). So, I can easily forgive svnrdump's > dump editor (and any other non-commit editor) for not supporting postfix > text deltas. That's one of two valid "modes" of an editor drive -- one > rarely used in practice. > > ra_serf has a well-established history (and intentional design) which > violates a far more fundamental editor restriction which applies to both > "modes" -- depth-first-ness. (See > http://subversion.tigris.org/issues/show_bug.cgi?id=2932 for details.) This > is why I'm more apt to think that the problem here is with ra_serf than with > svnrdump.
If it is determined that ra_serf's parallelism is at fault here, then we can force it to use a single connection for svnrdump. That should make it follow the right order. (and yeah, it sucks when you try to advance the capabilities and get yanked backwards into old-school mediocrity) Cheers, -g
