https://svn.apache.org/repos/asf/subversion/branches/atomic-revprop/BRANCH-README
The atomic-revprop branch, today, implements marshalling of the OLD_VALUE_P parameter over all RA layers to the repos and fs layers. (See svn_fs_change_rev_prop2() in trunk for a description of that parameter.) The branch does not yet promise a specific error code will be returned if the revprop change fails /due to the atomicity requirement/. Ensuring a specific error code is the bulk of the remaining work on the branch; implementing it requires teaching ra_dav how to marshal svn_error_t chains over the wire. In other words, the branch implements the API correctly and (from an FS-oriented point of view) completely, and only the ability to signal to the caller what sort of error condition occurred is absent. That absence means a caller cannot tell[*] whether the propchange failure was due to requesting an atomic change or due to some other reason. Is it fine to merge the branch to trunk, given this state? Is the branch, in its current state, fit for release (in 1.7), or is additional work (possibly including the abovementioned errorcode work) required prior to releasing it? Daniel (sleep-deprived) [*] There is a kludge-y workaround: see is_atomicity_error() in <http://mid.gmane.org/20100811004051.gb2...@daniel3.local>. It assumes that the server did not localize(translate) the error message.
