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

Re: ra_serf not providing a valid revision to delete_entry() upon update

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Mon, 19 Mar 2012 21:37:42 -0500

On Mon, Mar 19, 2012 at 8:03 PM, Hyrum K Wright
<hyrum.wright_at_wandisco.com> wrote:
> On Mon, Mar 19, 2012 at 5:24 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> On Mon, Mar 19, 2012 at 18:16, Greg Stein <gstein_at_gmail.com> wrote:
>>> On Mon, Mar 19, 2012 at 16:48, Hyrum K Wright <hyrum.wright_at_wandisco.com> wrote:
>>>> [ warning: investigation is still ongoing, but I thought I'd report this here.]
>>>> I'm trying to debug the Ev2 shims over ra_dav.  In doing so, I've
>>>> discovered an inconsistency between ra_serf and ra_neon (surprise!)
>>> ra_neon uses a "replay-report" while ra_serf uses an "update-report".
>>> The former provides the rev= attribute.
>>> I don't know why Neon uses the replay-report instead of the
>>> update-report. I dunno what the differences are.
>> What operations are you using? And why is it different between the two RA runs?
>> Note: in neon/fetch.c:1845, I see that SVN_INVALID_REVNUM is passed to
>> delete_entry(). That happens when ra_neon runs an update-report.
> You are correct, this code path uses neon/fetch.c:1845 on the ra_neon
> side, not the snippet I cited earlier.
> So the information is getting dropped over *both* ra_dav clients, not
> just ra_serf.  This is still a disconnect from that which is provided
> directly to the delete_entry() callback from the repository in
> reporter.c:916.  This bit of data is getting dropped.

The reason this bit of data was being dropped is that the delta editor
defines this as an optional piece of data. :( r1302758 attempts to
paper around the issue in the compat shims.


uberSVN: Apache Subversion Made Easy
Received on 2012-03-20 03:38:16 CET

This is an archived mail posted to the Subversion Dev mailing list.