On Fri, 2010-11-05 at 16:23 +0000, Julian Foad wrote: > On Fri, 2010-11-05 at 14:42 +0000, Julian Foad wrote: > > WC-NG gurus, > > > > Our WC-NG write-lock, as in svn_wc__acquire_write_lock() and > > svn_wc__call_with_write_lock(), is said to apply only to a directory and > > not to a file. However, in WC-NG it appears to me that doesn't make > > sense, because it applies to a *path* and WC-NG can have different node > > kinds in different op-depth layers at that same path. > > > > I am wondering whether the write lock should apply simply to a path, > > without trying to care whether that path "is" a directory or a file. > > > > In practical terms, we don't yet need to make 1.7 be able to replace a > > dir with a file or vice versa, we only need compatibility with 1.6, but > > this seems like a design issue that we need to address. > > > > Issues: > > > > * Is my thinking logically sound? > > > > * Are there some important semantics of write-lock that really only > > apply to a directory? > > > > * If we change this, how would we map between WC-NG write-locks and > > old adm_access write locks? Would it be sufficient to say that a WC-NG > > lock on a file would produce an adm_access lock on its parent, while an > > adm_access lock (which is always on a dir) would simply translate to a > > WC-NG lock on the same dir? > > > > * Is there any need to act to change this before 1.7? Although I have > > run into this issue in trying to sort out the "copy" code, I can live > > with it by always taking out a lock on the parent dir, regardless of the > > combination of node kinds at the child path.
For this "copy" code bug, I believe taking out a lock at the parent is the correct fix (and not just a "can live with it"). I committed that fix in r1031616. - Julian > > My feeling is also that such a change would result in an overall code > > simplification, but I can't actually demonstrate that. > > I discussed with Bert and Philip on IRC, and it seems the per-dir > paradigm is too deeply embedded, and any possible benefits too small or > unclear, to be worth pursuing this idea, at this time. > > Certainly there seems to be no need to change this. > > Interesting topic though :-) > > - Julian > >
