subversion-dev mailing list archives

Philip Martin <philip.martin@wandisco.com> writes:
> "Hyrum K. Wright" <hyrum_wright@mail.utexas.edu> writes:
>
>> On Nov 17, 2009, at 10:18 AM, Philip Martin wrote:
>>
>>> Philip Martin <philip.martin@wandisco.com> writes:
>>>
>>> r879744 did this:
>>>
>>> - SVN_ERR(svn_wc__adm_open_in_context(&adm_access, wc_ctx, path, TRUE, -1,
>>> - cancel_func, cancel_baton, pool));
>>> - err = svn_wc_remove_from_revision_control(adm_access,
>>> - SVN_WC_ENTRY_THIS_DIR,
>>> - TRUE, FALSE,
>>> - cancel_func,
>>> - cancel_baton,
>>> - pool);
>>> + SVN_ERR(svn_dirent_get_absolute(&local_abspath, path, pool));
>>> + err = svn_wc_remove_from_revision_control2(wc_ctx, local_abspath,
>>> + TRUE, FALSE,
>>> + cancel_func, cancel_baton,
>>> + pool);
>>>
>>> The change was made to remove an access baton from the client code.
>>> However inside the remove function the database needs to have been
>>> opened and the code above fails because no open has taken place.
>>> Where does the responsibility for opening the database lie? Should
>>> the client do it before calling the wc function, or should the wc
>>> function do it on demand? Looking at the current wc-ng API there
>>> doesn't seem to be a suitable open function for the client to call,
>>> everything still seems to be geared to access batons.
>>
>> The client shouldn't even *know* about the wc_db. All the client
>> has is an opaque svn_wc_context_t which it uses to do working copy
>> operations.
>
> So the answer to my question is that the wc library opens the
> databases as and when needed, on demand.
How is locking supposed to work? I have a better fix for the SEGV
than r881265, but without the call to svn_wc__adm_open_in_context the
on demand locks are read-only. I don't need the access baton, just
the write lock. I suppose libsvn_wc is supposed to upgrade read locks
to write locks on demand as well?
--
Philip