[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: atomic revprop commits at the RA level

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-08-10 16:01:24 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.