On Mon, 2009-09-28 at 03:13 +0000, Ian Clatworthy wrote:
> Robert Collins wrote:
> > I'm marking this as fix released for the following reasons:
> >  - comparing to hg one has to use shared repositories - hg hardlinks its database files together, which *doesn't actual clone or validate the data*. The analagous operation in bzr is branching within a shared repository, so that benchmark should be used, and with 2a we're very fast - faster than untarring a bz2 file in some benchmarks we did.
> >  - comapring to a git clone over the wire is more reasonable, and we've improvd a lot here too - I did a few tests not long ago showing both git and bzr were capped at network speed, where repository size starts to dominate
> >  - repository size is a big factor, and our 2a format brings that into line with git and hg.
> 
> My desktop is only months old with an i7 920 and 6G of memory. Branching
> OOo locally outside a shared repository takes 20 minutes!!! The bug
> isn't fixed so we shouldn't claim it is.

That copies all the history; I think 20 minutes is fine to do that much
work.

The question is 'is 20 minutes appropriate for cloning all the history
of a project the size of OOo' ? And I think it is.

> We could still do a lot to improve things:
> 
> * Disable data validation by default. If the source branch is busted,
>   creating each and every feature branch is *not* the time IMO to be
>   detecting the problem. We have 'bzr check' and it's the better
>   tool for validating the source branch integrity than running some
>   checks (but not all) during a branch (and only if the branch isn't
>   already in a shared repo).

Strongly against this. I think its a terrible idea. We've had terrible
outcomes in the past when we missed a step, and if we're going to change
this we should be adding stricter validation, not discarding it.

> * Detect that the target isn't in a shared repo and warn the user
>   that it will take a long time. Explorer does something like this
>   now: it suggests the user create a shared repo and pops up the
>   dialog for doing that if they agree.

That might be reasonable; certainly the UI focus on working with groups
of branches should be a component here.

> * Some other UI change so shared repositories are created by default.

Or some other mechanism to work with lots of branches in a single repo;
sure.

> > I'm certainly supportive of bugs like this, but we should try to keep
> > them focused, and this has become kindof a meta one, which is why I'm
> > closing it: its not a particularly useful bookmark for developers or
> > users.
> 
> I disagree. This problem is a major source of naive users blogging that
> "bzr is still slow. I grabbed a branch and cloned it and it took
> forever". Our out-of-the-box behaviour, on the command line at least,
> leads to terrible performance on the 'create a feature branch' use case.

Agreed. But *this bug* is about the specific 'how long it takes to do a
clone *outside* a shared repository'.

That time is appropriately long, IMO - we've put a lot of work into
making it faster than it was - and your OOo results are a testament to
the effect we've had.

Bugs like 'default setup causes users to profile things that they
shouldn't do' and 'its hard to setup bzr to work efficiently' are
important, but they aren't this bug: which is precisely why I've closed
this one:- fixing those things won't make history copying faster, and
we've gotten approximately where we wanted to get to on history copying
for new branches.

-Rob