Greg Stein <email@example.com> writes:
> > > > * 484: ra_dav:fetch.c:reporter_abort_report() must abort txn.
> > >
> > > DELETE the activity. Of course, the server doesn't understand that, but that
> > > is the correct wire marshalling.
> > DELETE is part of HTTP 1.1. Somehow mod_dav_svn needs to interpret
> > this request on a activity url??
> repos.c has a function for deleting things (dav_svn_remove_resource). Right
> at the beginning, it checks the resource type for WORKING. It should be a
> reasonably easy thing to add a check for ACTIVITY, and then to call a new
> function in activity.c which would abort the txn and delete the entry from
> the activities DBM.
Okay, I think this may be a waste of time. I now understand how
ra_dav is implementing the update reporter vtable:
RA->do_update() : create a tmpfile
reporter->set_path() : write xml to tmpfile
reporter->delete_path() : write xml to tmpfile
reporter->finish_report() : tell neon to pull xml data from tmpfile
reporter->abort_report() : remove tmpfile
So here's the deal. If the client ever needs to call abort_report(),
it will always be *before* it calls finish_report(). (Really,
abort_report() only happens if libsvn_wc stumbles while examining the
Unlike ra_local, when ra_dav gets an abort_report(), no server
transaction has been created yet... there's nothing to clean up!
I think there's no problem to solve here. The reporting-phase of
updates seems fine over the network.
I must have misdiagnosed the reason we were getting dozens of orphaned
transactions left on svn.collab.net; back when network updates were
failing (due to apache timeouts, etc.), it was always in the middle of
mod_dav_svn sending back a large update response. I bet that's why
transactions were being left behind. I bet mod_dav_svn isn't
perfectly cleaning up txns when errors happen. I'll take a look. (I
mean, at this moment, we still have 100+ orphaned transactions sitting
in our repository!)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:40 2006