Ben Collins-Sussman wrote:
> On 8/9/06, David Glasser <glasser@mit.edu> wrote:
>
>> The other alternative would be to deprecate svn_ra_get_commit_editor2
>> for an svn_ra_get_commit_editor3
>
>
> This is a feature we've wanted for a very long time. I think the only
> sane design is to extend our editor vtable to include a function for
> attaching properties to the transaction.
>
> Once upon a time, we envisioned the editor vtable as being perfectly
> symmetric... being used to commit from client to server, and to update
> from server to client. But it's already got a few asymmetries (like
> editor->set_target_revision, for example, which only goes from
> server->client.) A txn_propset function would be a new asymmetry, so
> it's ugly in a small sense, but overall I think it fits our design of
> 'how commits work'. If you want to do a commit, you get *one* vtable.
> It's a clean and simple.
>
> So I'd very much like to see a rev'd editor. As long as we're going
> to go through such pain... weren't there other things we wanted to add
> to the editor?
Sorry, but I oppose this. The editor is a mechanism for transforming
versioned trees, not transactions, not revisions. There isn't anything to
date in the editor that ties it to the idea that it is modifying a
transaction instead of just "some tree", and I see no reason to change that.
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?
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Aug 10 16:01:55 2006