On Dec 1, 2009, at 1:33 PM, Philip Martin wrote: > "Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> writes: > >> On Dec 1, 2009, at 10:31 AM, Philip Martin wrote: >> >>> "Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> writes: >>> >>>> On Dec 1, 2009, at 6:46 AM, Philip Martin wrote: >>>> >>>>> At the moment locking doesn't really work. For example: >>>>> >>>>> svnadmin create repo >>>>> svn co file://`pwd`/repo wc >>>>> svn mkdir --parents wc/foo/bar/zig/zag >>>> >>>> In this specific case, I can see us simply finding the parent >>>> directory which is a member of a working copy, and just locking it >>>> to depth infinity. This would implicitly lock any children, and >>> >>> There are no children when wc gets locked. >>> >>>> when that lock is removed, all the children would then be logically >>>> unlocked. (Or at least, that's what the little voice in my head >>>> tells me. If this reasoning is flawed, please let me know!) >>> >>> So we lock the wc database. Then we come to create the wc/foo >>> database we need to check the lock status of the parent database and >>> automatically propogate the lock from the parent into the wc/foo >>> database. Then the same for wc/foo/bar with wc/foo as the parent. >>> When we finally unlock the wc database it unlocks the wc/foo, >>> wc/foo/bar databases as well. >>> >>> Or do you see just a single lock in the wc database, and no locks in >>> any of the other databases? >> >> Yes. The explicit lock on wc/ has depth infinity, so when future >> iterations ask the question "is wc/foo/ locked?" the answer is "yes" >> via the implicit locking mechanism. wc_db callers only have to >> manage one actual row in the database, and other locks can be >> inferred from that row, in much the same way that access batons >> opened to infinite depth also open their children (only new children >> have to be explicitly opened in this case). > > So the answer to my question is a single lock in wc and no locks in > the children? That's not what we are doing at present. Currently > when I run update I see separate locks created in every directory.
Correct. We currently attempt to emulate the per-directory explicit locks from wc-1 inside the sqlite database. The idea of a single lock is expressed in the design doc, and one which I think better suits our usage patterns and metadata model. > [...] >> Regarding the easy use of svn_wc__db_read_info(), I agree. I >> believe the decision was that that API would tell a caller what it >> knew *right then*, and if that information wasn't known (i.e., it >> was NULL), the caller could then do what it took to get that >> information, either by recursing up the tree or some other means. >> read_info() is actually pretty dumb, and in all likelihood, requires >> helpers to make it useful. (Some of these have already started, see >> node.c.) > > What/where is node.c? subversion/libsvn_wc/node.c contains a set of functions mostly wrapping svn_wc__db_read_info(). These functions do stuff like recursive lookup for repos_relpaths. > [...] >>> One way to proceed would be to start by restricting locks in the >>> wc_lock table to those that have an empty local_dir_relpath. Then >>> each directories database would hold the lock for that directory, much >>> like the current lock files. >> >> This is exactly what currently happens. We don't programmatically >> restrict that value, but in practice, that's the only value which >> should end up in the wc_lock table. > > If I add > > SVN_ERR_ASSERT(!strcmp(local_relpath, "")); > > to svn_wc__db_wclock_set it causes over a dozen regression test > failures. That's a problem. I've added this assertion locally and am running the test suite to reproduce these failures. -Hyrum
