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
