Re: svn commit: rev 5687 - in trunk/subversion: libsvn_client libsvn_wc tests/clients/cmdline

kfogel@collab.net writes:

> > The associated baton is NULL, and the returned baton is not explicitly
> > closed, thus the lock only gets removed by a pool cleanup handler. Is
> > this intentional? Not explicitly closing write access batons has
> > cause me a problem in the past.
>
> What I'm worried about is the case where the baton was retrieved from
> the associated set. We don't want to close it in that case, I think,
> we just want to leave it where we found it. But if we got it via
> _open(), then we could close it.

Agreed.

> Is it worth adding a boolean and a check at the end of the code? I
> decided to just depend on the pool eventually being cleared, but now
> that you mention it, the code could fail if multiple entities are
> added in that parent directory.

Yes, that's the sort of thing that caught me in the past.

> Should the baton be unconditionally added to the associated set? That
> seems like an unwise side effect of the parent-updating code...

I don't think adding it will work, and so the boolean is required.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org