"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? >> 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. svn_wc__db_read_info is a very hard function to use. For example if I call it to get repos_relpath say, then I can't simply use the returned value because sometimes it's null. I need to examine something, status or the repos_relpath value I'm not exactly sure, and possibly search through the parents to get the real value. I suppose strictly speaking I don't have to worry about the location of the metadata, but it's not an easy to use interface. > 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. Obviously with enough effort we can make it work, it's just that it seems to be a long way off working at the moment. At the moment we can a) take locks that have no effect and b) make changes without locks. Apart from Julian's recent change there are no locking failures, but given the aparent absence of locking checks how can we have any confidence that locks are being taken correctly? 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. But perhaps we could do it differently: all the subdirectories could have an empty wc_lock table, or maybe no table at all, and all locks could be stored in the wc_lock table in the wc root. Essentially we could move to centralised locking before we move to centralised metadata. -- Philip
