On Wed, Jan 26, 2011 at 10:50 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> On Tue, Jan 25, 2011 at 8:31 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> ...
>>> * revv svn_diff.h#svn_diff_fns_t []
>>>
>>> It looks like, for the most part, any destabilizing functionality is
>>> completed, and what remains are simply optimizations. This
>>> optimization work can probably be performed on trunk, and if so, we
>>> should merge the branch back and do the cleanup work there. The only
>>> bit on the current list of stuff is revving svn_diff_fns_t. Can that
>>> work be parallelized?
>>
>> Yes, you are correct. Most of the essential work is done. Further
>> optimizations can just as well be done on trunk.
>>
>> Revving svn_diff_fns_t: what do you mean with parallelizing it? I must
>> admit that I don't really know (yet) how to go about that. Very early
>> during the branch work, danielsh pointed out that I modified this
>> public struct (vtable for reading data from datasources), so it should
>> be revved. Is it listed/documented somewhere what should be done for
>> that (community guide perhaps)?
>
> I was just wondering about how much could be done by other folks while
> you were working on the primary goal of the branch. (While any full
> committer can commit to the branch, it's generally good form not to
> step on people's toes.)
Oh yes, no problem. Any help with revv'ing that struct (or with other
parts of the code) is very much appreciated. Feel free to make any
changes necessary on the branch.
> I've updated the branch to trunk, and will start looking at rev'ing
> the struct and APIs.
>
>> (one slightly related note to this: I introduced the function
>> datasources_open, to open the multiple datasources at once (as opposed
>> to the original datasource_open, which only opens one datasource). But
>> maybe the new function should be renamed to datasource_open_all or
>> datasources_open_all or something, to make it stand out a little bit
>> more).
>
> Whatever you feel is best; I'm somewhat ambivalent about the name.
> The docstring does seem to be a bit lacking, however.
Yes. I guess I (or whoever takes a look at it) should go through the
docstrings (and inline comments) to see if they still describe things
accurately. Most of those date from the initial implementation on the
branch, so may be slightly out-of-date.
If I have some time, I'll try to take a look at it.
Cheers,
--
Johan
Received on 2011-01-27 02:16:22 CET