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

RE: Third (and probably last) alpha coming later this week

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 5 Jul 2011 11:41:07 +0200

> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum_at_hyrumwright.org]
> Sent: maandag 4 juli 2011 19:34
> To: Philip Martin
> Cc: Bert Huijben; Subversion Development
> Subject: Re: Third (and probably last) alpha coming later this week
>
> On Mon, Jul 4, 2011 at 10:37 AM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
> > "Bert Huijben" <bert_at_qqmail.nl> writes:
> >
> >> The issue Ivan Zhakov is looking at (r1141845, r1142065 and related)
> >> potentially breaks all current serf (and in some cases neon) clients
against
> >> a HTTPv2 server.
> >>
> >> (And without that patch serf always retrieves full-texts over HTTPv2)
> >>
> >> Please don't call out almost-RCs before we got that worked out :)
> >
> > Is there an issue describing the problem?
>
> Not that I can see. As per our project-wide consensus regarding
> branching and releasing and release candidates and such, nothing in
> the issue tracker means that there isn't a blocking issue.

I leave it to Ivan to create issues for this as he asked me *not* to fix
this issue on trunk because he needed more time to look for different ways
to resolve this problem.

(In one of his mails he also noted that there is a related problem with
neon, where I don't know the details or how to reproduce).

What I do know about this issue is:
In HTTPv2 for updates serf sends separate requests for every file/directory
that needs to be updated. As part of this request a header is sent which
indicates: Instead of the full text you can also send me an svndiff based on
this file at this revision.

In HTTPv1 we used to provide the dav-cached path for this (which works ok),
but in HTTPv2 we generate the path and revision based on local knowledge of
the working copy. But currently we still forget to look at switched paths,
so we often send some completely unrelated base-delta url, while we apply
the diff to the real base.

A bug in mod_dav_svn, which was fixed in r1141845 made us ignore the
base-delta header for all HTTPv2 requests, so the server always transferred
full-texts. So we didn't see the original problem at all, but fixing this in
mod_dav_svn uncovered the other problem.

With my knowledge on how the reporting and update phase of the update work I
was able to fix this problem. (This problem was actually found years ago but
never resolved: see the commented block in serf about guessing urls). I
committed the fix in r1142065, but only inside a #if 0 block.

Ivan then decided to revert his fix in mod_dav_svn as a temporary measure
until he had more time to look into this.

But now we have a compatibility problem: If we fix mod_dav_svn all serf
clients using HTTPv2 that don't have the currently still commented fix will
break.

So the reason that I asked to hold the 'almost-rc' a bit is that I don't
want it to be an 'almost-rc' that will certainly break against a final 1.7.0
which has a fixed mod_dav_svn.

But +1 for releasing the almost RC if we apply my fix first and (optionally)
fix mod_dav_svn.

        Bert
Received on 2011-07-05 11:42:05 CEST

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.