Comment 10 for bug 116094
Revision history for this message
| Ian Clatworthy (ian-clatworthy) wrote Re: [Bug 116094] Re: local clone without shared repository is too slow | #10 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
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.
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).
* 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.
* Some other UI change so shared repositories are created by default.
> 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.
Ian C.