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(&current_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.
> > 
> > 
> 

Reply via email to