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

Re: Speeding up the 'svn commit' process?

From: mark benedetto king <bking_at_inquira.com>
Date: 2002-07-10 15:19:45 CEST

On Wed, Jul 10, 2002 at 09:09:51AM -0400, Kevin Pilch-Bisson wrote:
> On Wed, Jul 10, 2002 at 08:55:50AM -0400, mark benedetto king wrote:
> > 2.) The library consumes its own API. While there's nothing wrong with
> > this, it does mean that nearly all of the exported functions would have
> > needed baton-ized versions. Take a look. There are a whole bunch of
> > exported functions.
> >
> > My feeling is that libsvn_wc needs to be split into two layers: one that
> > is baton-only, and another that consumes that one's API. This should
> > resolve (2), and make it easier to focus on (1). This will be a big
> > effort, but the payoffs could be huge. I measured, IIRC, over 90% of
> > client-side processing spent in manipulating the entries files.
> >
> I disagree. Rather, I think we should export the baton carrying functions, as
> well as two functions to create/finish with batons. Then the consumer of the
> API determines the life of the baton. This makes sense, since they are the
> only ones who know how long the operation is going to last.

Once we have a baton-driven API, we can look at the scope of pushing the
new API onto the existing libsvn_wc consumers. I didn't look at this, I
was trying to keep the change's scope down. It's possible that it would
be less work overall to push the API changes as well, rather than build
the "batonification" layer.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 10 15:24:58 2002

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.