Philip Martin <philip.mar...@wandisco.com> writes: > "Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> writes: > >> On Nov 17, 2009, at 10:18 AM, Philip Martin wrote: >> >>> Philip Martin <philip.mar...@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
