Re: atomic revprop commits at the RA level

David Glasser wrote:
> On 8/10/06, C. Michael Pilato <cmpilato@collab.net> wrote:
>
>> Extending the editor is *not* the "only sane design". For example,
>> look at
>> what svn_ra_get_commit_editor does today with respect to the commit log
>> message -- it accepts it as direct input and passes that data over the
>> wire
>> out-of-band with respect to the editor drive. Why not just drop the
>> 'log_msg' parameter from this function, and replace it with a generic
>> 'txn_props' hash?
>
>
> I'd think you'd still want to explicitly specify log message, since it
> wouldn't be good to end up with logless transactions, and making the
> client specifically know about "svn:log" (or SVN_PROP_REVISION_PROP).
>
> And I agree with Garrett that you might want to set the property later
> --- that would be good for revision signing, for example.

Alright. I can choke down the idea of putting this into the editor if we
can spin it like something generic, *not* as a "txn" or "revision" prop.
(Read: other ideas I've come up with lack either flexibility or finesse, or
both.)

Suggest:

  svn_error_t *(*change_edit_prop)(void *edit_baton,
                                   const char *name,
                                   const svn_string_t *value,
                                   apr_pool_t *pool);

The idea being we're modifying a property of the edit itself, not the tree
that's being edited.

Thoughts?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand