"Hyrum K. Wright" <[email protected]> writes: > On Dec 1, 2009, at 10:31 AM, Philip Martin wrote: > >> "Hyrum K. Wright" <[email protected]> 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. [...] > 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? [...] >> 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. -- Philip
