On Wed, May 16, 2012 at 9:43 AM, C. Michael Pilato <[email protected]> wrote: > On 05/16/2012 09:33 AM, Hyrum K Wright wrote: >> On Wed, May 16, 2012 at 8:15 AM, C. Michael Pilato <[email protected]> >> wrote: >>> ... >>> What to do about the commit Ev2 stuff? Perhaps you or Hyrum can help us >>> understand the scope of the performance cost paid by employing editor shims? >> >> The primary performance cost paid by Ev2 is that the entire edit is >> queued up during translation, and then replayed upon completion. >... > Are the shims required at all?
They are required for any RA provider that does not offer an Ev2 commit editor. At the moment, ra_local is the only RA layer which supports an Ev2 commit editor. ra_serf will provide one in the near term. (and I hand-wave / hope that somebody will step up to code something for ra_svn) > I mean, my recollection of the commit > process is that the client does a bunch of local investigation > (harvest_committables, etc.), but the actual drive of the commit editor is > handled in a single path-driver callback func. I don't have a sense of how > much of that initial state-gathering stuff you had to change to get Ev2 > commit drives working, so the following question could just be ridiculous, The gathering is independent of the commit drive. Bert has revamped the gathering completely [on trunk], and Hyrum rebuilt the commit drive on the ev2-export branch. > but: How hard would it be to temporarily maintain two commit paths -- one > that drives an Ev2 editor, and one that drives Ev1? The call to > svn_ra_get_commit_editorN() would return NOT_IMPLEMENTED from ra_neon (and > ra_svn), and the client would detect this and call the previous > Ev1-returning API and drive it accordingly? Certainly doable. And then it leads to a new question: "how long do we support these two commit drive code paths?", and it does not provide an answer for ra_neon itself. Cheers, -g
