WC write-locks: file vs. dir

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.

My feeling is also that such a change would result in an overall code
simplification, but I can't actually demonstrate that.

- Julian
Received on 2010-11-05 15:42:45 CET