[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: David Glasser <glasser_at_mit.edu>
Date: 2006-08-12 06:29:52 CEST

On 8/11/06, David Glasser <glasser@mit.edu> wrote:

> * No support in any of the WebDAV-related modules. I am not
> particularly familiar with any of them; I'd be happy if somebody who
> was wanted to write their implementations, but also could certainly
> dive in myself.

I looked into the WebDAV side of things. Interestingly, it appears to
me that mod_dav_svn already supports setting transaction properties:
the request that ra_dav and ra_serf use to set a new revision's log
message appears (though I haven't tested this) to also work for
arbitrary properties. It does not look like it would be incredibly
hard to make ra_dav and ra_serf use this feature.

The one bit that looks tricky here is that it looks like for ra_serf,
a txn won't actually be started during a call to ra_get_commit_editor;
it takes until the first open_root for the MKACTIVITY to go. (In
fact, ra_serf's get_commit_editor does no network activity at all.)
However, you really should be able to run set_revprop_for_commit
between get_commit_editor and open_root; you wouldn't be able to
combine it with ra_replay otherwise.

What downsides would there be to making ra_serf initialize its commit
in get_commit_editor instead of in open_root (like all of the other ra
modules)? I suppose it saves network resources if a client makes an
editor but never drives it, but that seems unlikely. (Note, by the
way, that my patch is already moving txn creation into
svn_*repos*_get_commit_editorN from its open_root.)

Anyway, more food for thought until folks get a chance to think about
this approach/patch.


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
Received on Sat Aug 12 06:30:20 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.