On Dec 1, 2009, at 6:46 AM, Philip Martin wrote: > "Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> writes: > >>> +Atomic Operations >>> +----------------- >>> +WC-NG operations that can operate without outside knowledge learned before >>> +the operation. >>> + >>> +These functions that are just one sqlite transaction by itself, just need >>> to >>> +make sure nobody else has a write lock. Having a write lock is not required >>> +for operations like just changing the actual properties on a node. Of >>> course >>> +nobody else can own a write lock, or it might change the properties after >>> +sending the commit data, but before moving the data to the base_node table. >>> + >>> +In a centralized metadata scheme, it is easy to check that nobody else has >>> +a write lock. (Checking if we ourselves have a write lock ourself is just a >>> +memory lookup of course). >>> + >>> +Partial Operations >>> +------------------ >>> +These operations rely on data read before the wc_db operation and only work >>> +correctly if the data didn't change since reading. All entry based >>> operations >>> +are in this category and the WC-NG work tries to redesign several of these >>> +operation to the first class of operations. > > 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 > > The mkdir creates unversioned directories and then calls > svn_client_add4. The only lock that gets created is on > /path/to/wc/foo/bar and that results in a lock for "foo/bar" in the > database in wc. That may make sense when we move to a single database > but it doesn't look right for multiple databases. No other locks get > created, which means three directories get added without locks and > nothing fails. > > After the mkdir status shows the added directories and no locks, however > $ echo "select * from wc_lock;" | sqlite3 wc/.svn/wc.db > 1|foo/bar > shows that the "foo/bar" lock still exists in wc despite the absence > in status. There is no lock in wc/foo or wc/foo/bar, which is not > really surprising since no other locks ever got created. > > The new versioned directories are not locked when they first become > versioned. Perhaps that is an atomic operation and doesn't need a > lock? If so that means that some other process could delete > wc/foo/bar/zig before we get to add wc/foo/bar/zig/zag. Will that > cause the overall mkdir to fail? That won't play nicely with mkdir's > error handling.
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 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!) > As far as I can see locking is currently pretty close to being > completely broken. Are we going to try and fix it before we move to a > centralised database or do we just abandon locking? No. I don't think abandoning locking is prudent or needed. Assuming the design meets our anticipated requirements, I think we can move forward with it even without centralized metadata. We can implement the wc_db APIs in such a way that they process and return locks consistent with the design, and then let the implementation worry about where those locks are actually stored, and what we need to do to find them. In this way, callers are freed from worrying about where the metadata actually lives, similar to svn_wc__db_read_info() and friends. Assuming (and this is a big assumption) the design passes muster, I'd like to do some of the locking implementation work over the next few days to see how it works out. Critical review highly appreciated. (I noticed that Julian added a check for the working copy status to one of the tests, which is now causing it to fail across the board. Perhaps we should WIMP the test to prevent the distraction for others, with the understanding that we (I?) are working to address the problem?) -Hyrum
