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

Re: Status of 1.7.3

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Thu, 9 Feb 2012 10:18:59 -0600

On Thu, Feb 9, 2012 at 10:13 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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 may do many things, but honoring the Ev1 ordering rules is
not one of them. The violations are legion, but suffice it to say
that if the svnrdump editor is not driven in a precise manner--which
is some subset of that allowed by Ev1--all bets are off.

Some of these problems, such as re-using an editor for multiple
revisions, have been fixed on trunk, and may be candidates for
backport. Others, such as the reliance on the editor baton to store
everything, are a bit more fundamental, and may require more work to
get right.

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-02-09 17:19:33 CET

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.