Re: atomic revprop commits at the RA level

On 8/14/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> > I know one interesting idea that floated by (in IRC) was to create a
> > *new* vtable. This vtable would contain metadata funcs, and also an
> > editor...
>
> This is why I got over it. I started to propose this very thing last week,
> but when I realized just how awful it was, I folded.

Yeah; right now it looks to me that making r(epos|a)_get_commit_editor
return a new vtable containing a set_prop and an editor might not be
too bad, but trying to move set_target_revision out to the "meta"
vtable looks a little crazy, since as far as I can tell the majority
of the APIs that use editors end up using it anyway (for better or for
worse).

> That's why I proposed 'editor->change_edit_prop()'. It wasn't really that I
> was opposed to the editor carrying metadata about the edit, it was that
> editors shouldn't know anything about txns as revisions-in-progress (though
> I might not have expressed that well). But as long as we talk about "edit
> metadata" (which *we* know is a mechanism that can be used for, among other
> things, carrying txn props), it doesn't rub me quite as wrongly.

OK. So let's say we're going to do this. Does this seems like a
reasonable plan:

* Revise svn_delta_editor_t to have a change_edit_prop whose default
implementation returns an error, and upgrade all ~50 APIs that use it.
* Make the change_edit_prop returned by svn_repos_get_commit_editorN
actually set the txn property.
* Modify the ra backends and frontends so that the editors returned
from svn_ra_get_commit_editorN so that they support the property.
* (Maybe) Add a boolean to r(epos|a)_replay which asks it to issue
change_edit_prop calls.

Two questions:
* While we're going to the trouble of changing svn_delta_editor_t and
thus adding compat versions of ~50 APIs, does it make sense to make
the new editor type opaque (so that future additions of
default-erroring methods wouldn't require changing all the APIs)? Or
would that lead to other problems (like breaking bindings or
something)?

* Should change_edit_props be allowed before open_root? If not, then
we definitely need to make the change to r(epos|a)_replay. If so, some
code in repos and ra_serf will have to be changed to do some
initialization in get_commit_editor instead of in open_root (or to
cache edit prop changes until open_root); I'm not sure why those
editors choose to wait until open_root to really start things, and if
it's important behavior to preserve.

--dave

-- 
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org