mbk nominated r10467 and r10734 for backport to 1.1. I've decided I
have a little disagreement with how it works, and want to bring up the
issue on the list so we can resolve it and the get the change into
1.1.
What we do now is print "This may take a while...", silently attempt
to grab the lock, and then recover. This is bad because if we're
taking a long time, the user has no idea whether it's because of the
lock (which the user probably doesn't even know about) or because DB
recovery is slow.
mbk's change adds a nonblocking flag to svn_repos_recover (via a new
function yadda yadda). The recover flag tries svn_repos_recover2 with
the nonblocking flag; it it fails, it prints a warning about the lock
and tries again without the nonblocking flag.
Although this is definitely better than the status quo, my
disagreement is that the user doesn't find out whether recovery has
started, and thus doesn't know whether the recovery process can be
safely interrupted.
The easiest alternative is to just bomb out if we can't get the lock
immediately. A harder alternative (because it requires a tricky API
decision) is to retry with a blocking lock, but print a message once
we get the lock.
I kind of like the first alternative, because even if we print a
message once we get the lock, the user has to perform a little dance
in order to safely kill off the recovery attempt (^Z it, see if the
message was displayed before the process was stopped, then continue).
However, mbk points out that if svnserve is running out of inetd, it
can be convenient to have the recovery process waiting in line to get
the lock, since it's hard to ensure that inetd won't kick off an
svnserve process and grab a read lock.
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 this is a straightforward weighing of tradeoffs, so we can
just collect preferences, but feel free to make new arguments if you
have them. If you want to side with the "other alternative," please
mention what kind of API you'd like to see for it--either a
notification callback to svn_repos_recover2, or separating out the API
to grab the exclusive lock (so svn_repos_recover2 would have the same
signature as svn_repos_recover, but would assume that you've already
grabbed the lock).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 29 00:25:42 2004