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

aborting txns (WAS: Re: state of union)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-09-12 19:00:47 CEST

Greg Stein <gstein@lyra.org> 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
working copy.)

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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006

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.