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

Re: SQLite and callbacks

From: Branko Čibej <brane_at_e-reka.si>
Date: Sat, 05 Feb 2011 18:47:35 +0100

On 05.02.2011 15:35, Stefan Sperling wrote:
> On Sat, Feb 05, 2011 at 03:29:23PM +0100, Stefan Sperling wrote:
>> I think we should strongly consider revving affected callbacks in the
>> 1.7 API and document restriction they have to heed. Then we can bring
>> the r1039808 code back. We can keep the code added in r1066541 for
>> backwards-compatibility if desired.
> By the way, I think this decision is very important for progress of wc-ng.
> And I also think it has way too much impact to be decided on a lazy consensus
> basis. So I'm *not* going to move forward with this before I've heard at
> least a couple of affirmative opinions. Please consider taking the time
> to think about this issue and let your opinion be heard. Thanks.

In that case it would make sense to create a completely new set of APIs
(with a correspondingly new set of callbacks) with different
restrictions so that the implementation can be made fast, i.e., by doing
one query per working copy instead of one per directory or per-file.

I would not worry about existing clients -- simply mark the existing
APIs as deprecated, but keep them and do not attempt to improve their
performance. Clients that are being actively developed will move to the
new, faster infrastructure sooner rather than later. Those that are not
being maintained, or whose maintainers don't want to bother with
changing them, will remain bog slow and slowly fall by the wayside. We
should not be in the business of trying to improve other people's code
for them, only give them the tools to do so if they want to.

In short -- +1 to this approach. If it's not taken, then the whole wc-ng
effort will (almost) have been in vain as far as end users are concerned.

-- Brane
Received on 2011-02-05 18:48:21 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.