On Wed, May 16, 2012 at 9:43 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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.
>...
> 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
Received on 2012-05-16 16:13:38 CEST