On 8/14/06, David Glasser <email@example.com> wrote:
> svn_ra_replay and svn_repos_replay2 do essentially the same thing at
> different layers... except that svn_ra_replay calls close_edit on its
> editor after the replay is done, and svn_repos_replay2 doesn't. At
> the very least, this inconsistency should be documented in 1.4.
> I'd prefer, though, that ra_replay just shouldn't call close_edit at
> all. Not only is this more consistent, but it also is more flexible;
> for example, in the theoretical future where we can set revprops
> atomically over RA, we might want to slip set-revprop calls in between
> ra_replay and close_edit.
> The following patch implements this. It is mostly a matter of removing
> close_edit calls, and adding a close_edit to svnsync (the only client
> of svn_ra_replay). This means that you can test this patch by running
> the svnsync command-line tests; I've done this for ra_local, ra_svn,
> and ra_dav, but not for ra_serf, because I don't have serf installed
> on this machine yet.
> The one tricky bit is that in order for svnserve to tell the client
> that the replay is done without asking it to close (or abort) the
> edit, I've added a "finish-replay" command which just switches from
> the current editor session back to whichever command set was running
> before it; this required upgrading an svn_ra_svn.h API to allow
> specifying whether or not a given editor session is a replay session,
> so that finish-replay can be an error outside of replay.
This seems good to me. I've committed it to trunk (with a few minor
tweaks, mostly breaking overly long lines) and proposed it for
backport to 1.4.x.
It's going to need a backport branch for us to vote on it, since the
diff doesn't apply to the version of mod_dav_svn in 1.4.x (maxb's
refactoring in trunk moved the location of the code for the replay
report, among other things). I may not get around to that in the next
few hours, as I need to head to the airport fairly soon, but if it
hasn't been taken care of by the time I get to a network connection on
the other end of the trip I'll handle it.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Aug 15 18:35:09 2006