atomic revprop commits at the RA level

[I couldn't find anything in the archives about this when I searched;
I suspect this says more about my searching skills than anything else,
so sorry if this has been discussed a lot before.]

Currently the repos/fs layers allow for revprops to be set on new
revisions atomically when they are committed, by setting "transaction
properties"[1]. However, the ra layer doesn't allow that:
svn_ra_commit_editor2 just returns a standard svn_delta_editor_t and
doesn't give any hooks to say "and set this revprop on this revision".

This would be a useful feature for several reasons; for example, it
would make repository mirroring tools like svnsync and SVN::Mirror
much simpler, and it would allow the enforcement of policies like "can
only commit revisions that have been cryptographically signed with the
signature in some revprop". It would also help with Issue 1976.

I'm interested in giving this a shot. I'm not quite sure how to make
its API, though.

The ra layer specifies that between calling svn_ra_get_commit_editorN
and finishing the edit on its associated editor, the caller may not
perform any other RA operations. Thus, one way of adding this feature
would to make an API like:

svn_error_t *svn_ra_set_rev_prop_for_commit(svn_ra_session_t *session,
                                            const char *name, const
                                            svn_string_t *value,
                                            apr_pool_t *pool)

and specify that it's *only* legal to call this in the time between
svn_ra_get_commit_editorN and its close_edit (or abort_edit). This is
nice, because it's minimally invasive --- it doesn't even invalidate
any old APIs, just relaxes one of the constraints on use.

On the other hand, it seems a little odd to have a "get_commit_editor"
call whose main feature is to return a commit editor, but to then have
something affecting the commit not go through what it hands back at
all but rather go straight to the session. While as far as I can tell
it wouldn't be too hard to implement what I've described (well, I've
only looked at ra_local and ra_svn so far), it does smell a little of
"action at a distance".

The other alternative would be to deprecate svn_ra_get_commit_editor2
for an svn_ra_get_commit_editor3 which returns a "transaction baton"
or something instead of an svn_delta_editor_t; every normal delta
editor call would need to have an extra indirection to get at the
editor, but this object would also support the "set revprop"
operation. This seems like a pretty huge change for a relatively
minor feature; while it's certainly backwards compatible, it seems
like it would annoying for users of svn_ra who don't care about this
feature to upgrade.

So is the former API clean enough to be worth implementing, or is the
latter not too invasive, or is there some other option that I'm
completely missing?

--dave

[1] Whose purpose is as far as I can tell not actually documented in
    svn_fs.h; I'll send a patch separately.

-- 
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