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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-02-09 18:27:04 CET