On Wed, Aug 11, 2010 at 03:51:38AM +0300, Daniel Shahaf wrote:
> (hitted "send" too soon)
>
> Daniel Shahaf wrote on Wed, Aug 11, 2010 at 03:40:51 +0300:
> > For the last few weeks I've been working on the atomic-revprop branch.
> >
> > (Its goal is port the new svn_fs_change_rev_prop2() to libsvn_ra, which
> > should allow callers to specify both a value and an optional "previous
> > value" and have the revprop change atomic; see [1].)
> >
> > Currently, the API is implemented over all RA layers, and the test (prop 34)
> > passes.
> >
> > To extend svnsync to use the new API for acquiring locks,
>
> To extend svnsync to use the new API for acquiring locks, I'd like to make
> the API guarantee which error code it returns in case the atomic expectation
> didn't match the actual value (if any) found. This requires some work on
> ra_dav client/server to make them pass the error code on the wire (like
> ra_svn already does) --- per earlier thread this week [2].
>
> Until then, I have a working patch for svnsync, which --- until said ra_dav
> work is implemented --- relies on checking the error message (that's what I
> have available) rather than the error code. That patch is attached to the
> previous mail in this thread. (I'll commit that after the "check the error
> message" hack is removed.)
>
> That's all for now I suppose. A roadmap of the work can be found in
> BRANCH-README [3].
Thanks a lot for working on this! The svnsync locking problem is really
annoying, as it breaks replication setups that follow the svnbook.
The BRANCH-README suggest that we add an interface like
'svn propedit --revprop pname pval2 --old-value=pval'.
I don't think there is a valid use case for non-atomic revprop changes.
Why not just make all revprop changes atomic by default if the client
and server are both >= 1.7? Any propset/propedit operation could
transparently retrieve the old value before trying to set the new value.
Stefan
Received on 2010-08-11 12:23:44 CEST