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

Re: mbk's recovery lock change

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2004-08-30 14:26:34 CEST

On Sat, Aug 28, 2004 at 06:25:31PM -0400, Greg Hudson wrote:
>
> So, to summarize:
>
> What we have now: No diagnostic, blocking lock attempt
> mbk's alternative: Diagnostic if we can't get lock, then block
> My alternative: Fail if we can't get lock
> Other alternative: Diagnostic if we can't get lock, then block,
> and print another message when we do get lock
>

I think Greg's suggestion is reasonable.

Some points in favor of the "blocking" approaches are:

1.) Unless there is an actual unrecoverable problem with the repository,
    they can run to completion without error.

2.) There is no starvation potential (presuming that the locking primitive
    guarantees no starvation). This is offset somewhat by the fact that
    the repository administrator almost always has at least the priveledge,
    if not the desire, to shutdown svnserve/apache/inetd in the case where
    they are having trouble obtaining the lock.

Hmm... maybe there's some middle ground...

The difference between Greg's suggestion and the trunk code is that
Greg is proposing that we remove the blocking call to svn_repos_recover2.

This sounds like a job for a command-line option!

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 30 15:57:08 2004

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.