On Tue, Apr 21, 2009 at 20:01, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
>
> On Apr 21, 2009, at 12:57 PM, Greg Stein wrote:
>
>> On Tue, Apr 21, 2009 at 19:49, Hyrum K. Wright
>> <hyrum_wright_at_mail.utexas.edu> wrote:
>>>
>>> On Apr 21, 2009, at 11:37 AM, Greg Stein wrote:
>>>
>>>> On Tue, Apr 21, 2009 at 18:32, Hyrum K. Wright <hyrum_at_hyrumwright.org>
>>>> wrote:
>>>>>
>>>>> Author: hwright
>>>>> Date: Tue Apr 21 09:32:55 2009
>>>>> New Revision: 37413
>>>>>
>>>>> Log:
>>>>> * subversion/libsvn_wc/adm_ops.c
>>>>> (erase_from_wc): Close the directory's access baton before attempting
>>>>> to
>>>>> blow away its contents.
>>>>
>>>> You're not the code that opened it. You can't simply close it.
>>>
>>> If I don't close it, nobody will. Further down in this function, we
>>> attempt
>>> to blow away that directory. After that, nobody *can* close that baton.
>>
>> Child directories are closed during parent-close. See lock.c::do_close().
>>
>> I think we may need a new access baton state. The user can think they
>> still have it "open", but internally we sorta-close the thing.
>
> Are we still going to have the notion of per-directory open/close for the
> access batons in wc-ng? It seems that adding a new state wouldn't be very
> useful in the long term.
I really don't know.
I've just kinda been iterating to move things along, to get a handle
on the stuff, and to simplify some interactions. It is still pretty
unclear of our final positioning for access batons. I *believe* their
internal state is now at the minimum for backwards compat (ie. I don't
think we can remove anything).
But with that said, I still disagree that you can just call close() on
the baton. It isn't yours.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1846754
Received on 2009-04-21 20:39:25 CEST