[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.

--ben

---------------------------------------------------------------------
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.