Philip Martin <philip.mar...@wandisco.com> writes: > Stefan Sperling <s...@elego.de> writes: > >> I don't have the time to look deeper into it right now, and would >> appreciate if someone could investigate. To reproduce the crash, >> follow the steps outlined in issue #3530 and remove the NULL check >> added in the above commit. > > r879744 took out the code that opened the external wc. Since the wc > doesn't get opened it can't be deleted. Your change doesn't work > because the wc that didn't get deleted remains to obstruct the update.
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. -- Philip
