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?
[*] There is a kludge-y workaround: see is_atomicity_error() in
<http://mid.gmane.org/20100811004051.GB2294@daniel3.local>. It assumes
that the server did not localize(translate) the error message.
Received on 2010-09-17 09:18:52 CEST