On 05/16/2012 09:33 AM, Hyrum K Wright wrote:
> On Wed, May 16, 2012 at 8:15 AM, C. Michael Pilato <cmpilato_at_collab.net> 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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-05-16 15:43:48 CEST