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. Some > of this intermediate queuing happens in memory, other bits happen on > disk, but suffice it to say that for large commits, such intermediate > storage may be prohibitive. I don't think it would be a problem for > day-to-day work, but for large merges which are common in some > organizations I know of, such a performance penalty would be > prohibitive. > > Greg's been hacking around in the shims, and has reduced this cost > somewhat, but there is still a O(n) additional resource use cost to > consumers of the shim code.
Are the shims required at all? 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, 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? -- C. Michael Pilato <[email protected]> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
