On Wed, Aug 25, 2004 at 10:06:49AM +0100, Andy Whitcroft wrote:
> > Second, how we're improving things: in svn 1.1.0 (but not in 1.1.0-rc2,
> > I believe), when we grab the exclusive lock for recovery, we will do it
> > in a non-blocking fashion, and simply fail out if we don't get it.
>
> Saw this in reply to a recent rant and that got me to looking at the code to
> see if there is any possibility of recording the lockers. That aside I was
> looking at the changes as commited for the non-blocking code. I see you
> (assuming svn ann is correct) have added an svn_repo_recover2(). Two
> comments on the change is it stands:
I don't think it's possible to reliably and portably record the lockers.
That aside, you are correct.
>
> 1) do we not assume that when an xxx2() is introduced that the xxx() is going
> away, that cirtainly is my understanding. If so then the second blocking
> call should also be modified to the new interface. Patch below.
Sure enough, HACKING does state that when one creates an xxx2(), one should
deprecate xxx().
I'll apply this patch soon.
>
> 2) in introducing a new parameter for the blocking/non-blocking status perhaps
> it might be nicer to make that a general flags field for this operation
> taking xxx_RECOVER_NONBLOCK or something in the non-blocking case. Thus if
> some other new fangled modifier is needed there is a simple compatible place
> to add it?
>
I thought about that, but couldn't think of any other likely flags.
If it were a function likely to grow several more boolean options,
I probably would have gone with a flag-based approach for better
extensibility, as you have suggested.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 26 13:15:18 2004