Daniel Shahaf wrote on Wed, 16 Jun 2010 at 01:19 -0000: > Philip Martin wrote on Tue, 15 Jun 2010 at 11:16 -0000: > > Philip Martin <philip.mar...@wandisco.com> writes: > > > Putting the get, pre hook and set into a transaction would allow the > > > action in the hook to accurately reflect the change made (or not made > > > if the transaction fails). > > > > We don't need a new transaction to fix this, we can rev the > > svn_fs_change_rev_prop interface instead: > > > > svn_error_t * > > svn_fs_change_rev_prop(svn_fs_t *fs, > > svn_revnum_t rev, > > const char *name, > > const svn_string_t *value, > > apr_pool_t *pool); > > > > to include the current value of the revprop, and then reject the > > change if the current value does not match. That should be simple > > because the FSFS implementation already takes a write lock and the BDB > > implementation already uses a transaction. > > > > Testing a patch for this ^. >
r955136. Comments welcome :-) > Daniel > > > Then the repos layer can loop (in practice only if the > > use_pre_revprop_change_hook flag is set): > > > > do > > svn_fs_revision_prop(¤t_value) > > action = ... > > svn_repos__hooks_pre_revprop_change(action) > > error = svn_fs_change_rev_prop2(current_value, new_value) > > while error is current value doesn't match > > > > This doesn't alter the fact that the revprop can change at any time > > during the loop but that doesn't matter. The revprop is unversioned > > so only the current state matters and the above will guarantee that > > the current state when the change is made is equal to the state > > validated by the pre-revprop-change hook. > > > > >