[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Status of the branch diff-optimizations-bytes branch

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Thu, 27 Jan 2011 09:52:19 -0600

On Wed, Jan 26, 2011 at 7:15 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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'd appreciate review on the attached patch. It is an attempt to rev
the svn_diff_fns_t struct and related functions. You'll notice that I
commented out the use of datasources_open in both diff_file.c and
diff_memory.c, in an attempt to exercise the deprecated function

It currently segfaults horribly, but I'm not completely sure why. I
suspect something is amiss in the implementation of the compat wrapper
for datasources_open in deprecated.c. If you'd review this patch, I'd
be much obliged.


Received on 2011-01-27 16:53:00 CET

This is an archived mail posted to the Subversion Dev mailing list.