"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. 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? -- Philip
