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.
>
> 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
Received on 2010-11-05 17:24:39 CET