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
>
>
Received on 2010-11-05 19:33:58 CET