On Feb 9, 2012 12:26 PM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
>
> On 02/09/2012 11:41 AM, Philip Martin wrote:
> > "C. Michael Pilato" <cmpilato_at_collab.net> writes:
> >
> >> On 02/09/2012 05:22 AM, Philip Martin wrote:
> >>> Hyrum K Wright <hyrum.wright_at_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
Received on 2012-02-09 18:36:14 CET