Re: svn commit: r1558224 - in /subversion/trunk/subversion:libsvn_fs_fs/tree.c libsvn_fs_x/tree.c tests/libsvn_fs/fs-test.c

Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:

> As you already figured out, there is an explicit check in
> the repos layer that prevents property changes on dirs
> that are not at the txn base revision, i.e. node-HEAD at the
> time of the begin of that txns. The reason is that the API
> does not actually have a "change prop" but only a "set
> prop" function. Prop changes to the same node between
> wc BASE and txn base would simply be lost.

The repos/RA layers could implement the more relaxed check of the FS
layer but it is probably not a trivial change, and it would not match
the BDB backend.

> So, we still have a theoretical scalability issue but now
> it is the time a "svn up --depth=empty" at the root node
> (in theory a constant value) that should be less than the
> average time between commits.

Agreed, the current code does improve concurrency. In my example:

$ svn st wc1
M wc1/f

$ svn st wc2
 M wc2
M wc2/g

With 1.8 the commit of wc2 fails if wc1 is committed first. With trunk
wc2 still fails if wc1 finishes before wc2 starts. The new behaviour is
that if wc1 and wc2 start in parallel, so that wc2 passes the repos/RA
checks before wc1 finishes, then wc1 can finish before wc2 and wc2 still
succeeds.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*