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

Re: Cancelling Subversion operations

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-09-22 19:58:53 CEST

On Sunday, September 22, 2002, at 01:50 PM, Branko ╚ibej wrote:

> Can't be done, I tried. The only way to unwedge a repository is to run
> recovery in a process that has exclusive access to the repo. If there
> are wedged processes hung there, it won't work. The only way to avoid
> hanging a process is to set a timeout on DB locks and transactions
> (can be done in the DB_CONFIG file). Then you have to guess a correct
> timeout period.
> The automatic unwedging thing would work great if we had a DB server
> process. But we don't.

well, given this problem, there are a couple of routes we can take.

first, do we consider this potential for the repository to lock up
(without losing data) a show stopper?

if yes, then we need to pursue one of the ideas regarding sentinel
processes that mediate access to the db.

if not, then it seems prudent to make every effort to make it as
difficult as possible for the user to get into this situation. adding
cancelation support seems like a good step in this direction.

personally, i don't feel that it's a show stopper, as long as we try to
make it happen as little as possible, and provide good ways to clean up
(philip's proposed changes to svnadmin seem reasonable to me).

either way, i think adding cancelation support is a good idea, and the
question regarding that is: do we do it the way branko suggested (using
SVN_ERR), which i already have implemented, or do we want to have a
more invasive, but potentially cleaner for a multithreaded client,
solution like what bill proposes.

as one might expect, i vote for the patch i've got ;-)

i think it solves the problem we have now, it provides a means for
multithreaded clients to handle the issues associated with having
multiple cancelable svn functions happening at the same time, and it
doesn't have a huge effect on our codebase. i like the fact that this
is concealed behind SVN_ERR, and that we get cancelation practically
for free in almost all parts of the codebase.



garrett rooney                    Remember, any design flaw you're
rooneg@electricjellyfish.net      sufficiently snide about becomes
http://electricjellyfish.net/     a feature.       -- Dan Sugalski
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 22 19:59:27 2002

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.