I don’ t think the strict ordening will be a problem for old clients at the client level. We don't promis ordering in the ra layers anyway and we have changed the ordering many times before. As long as we call the callbacks I think clients would be fine. And it will solve the existing problem of broken operations when the network layer times out on a long callback invocation.
Bert Sent from Windows Mail From: Julian Foad Sent: Tuesday, March 26, 2013 9:18 PM To: Stefan Sperling Cc: Subversion Development; Bert Huijben; Stefan Küng Stefan Sperling wrote: > On Tue, Mar 26, 2013 at 04:26:33PM +0000, Julian Foad wrote: >> With this patch, subversion/svn/update-cmd.c:svn_cl__update() will do this: >> >> * Call svn_client_update4(...) >> >> - with ctx->conflict_func2 set to svn_cl__conflict_func_interactive() >> which does interactive or non-interactive (pre-specified) resolution. >> >> - which calls the callback after completing the update, before >> returning. > > I agree that this makes more a whole lot more sense, and would > like to see the 1.8 API behave this way, if GUI clients can deal > with it. > > What about third-party callers that call the 1.7 and earlier APIs? > Their callbacks will be called at a different time when they run > against 1.8 libs, won't they? Is this a problem? Good point. I think we should preserve the behaviour of the old APIs exactly. I'll make that happen. >> This changes the notifications a bit, as mentioned in the log message >> (which is in the patch file). > > This might also be a backwards-compatibility concern. > > If possible, we should try to keep the old APIs working as-is. > I think this was part of the rationale for doing this within 'svn'. As above. The changes in notification are very closely tied to the changes in when the CB is called. I'll make both happen the old way when calling the old API. This will extend the patch a bit, and result in bumping the svn_client_update/switch API versions. - Julian
