On Mon, Mar 19, 2012 at 8:03 PM, Hyrum K Wright <hyrum.wri...@wandisco.com> wrote: > On Mon, Mar 19, 2012 at 5:24 PM, Greg Stein <gst...@gmail.com> wrote: >> On Mon, Mar 19, 2012 at 18:16, Greg Stein <gst...@gmail.com> wrote: >>> On Mon, Mar 19, 2012 at 16:48, Hyrum K Wright <hyrum.wri...@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. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
