[darcs-devel] announcing darcs 2.0.0pre1, the first prerelease for darcs 2

[David Roundy]

On Sun, Dec 16, 2007 at 01:12:21AM +0100, Alexander Staubo wrote:
> On 12/14/07, David Roundy <droundy at darcs.net> wrote:
> > You don't need to call optimize on the repository that is used to create
> > the tag, and you shouldn't need to do so very often.
> 
> Ah, I thought perhaps you needed to do this in order to reduce the
> search space on both sides of the exchange.
> 
> > > In my experience, Darcs pulls/pushes speed up dramatically if you
> > > optimize, but performance starts to trail once you start adding
> > > patches, and quickly becomes painfully slow. Eric Kow's advice is to
> > > optimize every 30 or so patches, which seems to match my experience.
> >
> > With hashed repositories, this shouldn't be a big issue for pushes and
> > pulls, at least if you're dominated by network IO costs (which is often the
> > case), because patches that you've already seen won't need to be downloaded
> > again.
> 
> Not sure what you are saying here -- are you saying that the
> incredible, wonderful performance improvement we are seeing after each
> optimize is not a big issue? We are suffering the weird OpenSSH bug on
> the Mac that prevents us from using SSH connection sharing, so we're
> definitely network-I/O-dominated.

You aren't using hashed repositories, are you? You won't see that
incredible, wonderful performance improvement from optimize, because you'll
already get it when you switch to hashed repositories, since then you won't
need to download any patches that have been downloaded on a previous darcs
pull or push.  It'll be even better if you enable a cache, but just using
the hashed format in your situation will solve the problem.
-- 
David Roundy
Department of Physics
Oregon State University