Merging a bundle w/ a pack repository is slow

Aaron Bentley aaron.bentley at utoronto.ca
Fri Nov 30 23:34:05 GMT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Thu, 2007-11-29 at 23:04 -0500, Aaron Bentley wrote:
>> At minimum, we
>> would need a way of finding the ancestry difference between two
>> revisions' ancestries that is trustworthy and has nice scaling properties.
>>
>> Until we have that, there are many get_ancestry calls we can't eliminate.
> 
> I haven't profiled graph.difference(); is it not good? I'll be happy to
> work on that if thats a key element to eliminating get_ancestry.

No, it's not trustworthy.  It can be tricked by history shortcuts.  I
would love it if you'd help with that.  There are still loads of places
I'm aware of where get_ancestry is used in order to do a set difference.

>> If you are proposing to fix it before 1.0, okay.  But if the release
>> slips or performance is bad because of your no-compromise attitude, I
>> will not be happy.
> 
> I've ack'd that we may need john's workaround for release branches.

Thank you for being more pragmatic about this.  I am also being
pragmatic by working on per-file-graph merging, when I think annotate
merge is a better long-term solution.

Part of the reason I run bzr.dev is so that I see problems before our
users do.  In principle, I'd rather not have a patch that's only applied
to releases, because it wouldn't be very well tested.

> I think that if packs are not good enough *across our core commands* with
> the current code base, that they should not be default. 

Fully agreed.  (Pretty hard to disagree with that!)  But I would add
that I think we shouldn't release 1.0 until we can make them default.

>>> We're not punishing code that uses bad api's, we *removing* the
>>> constraint that made bad apis no worse than good api's
>> Actually, we're doing a third thing: punishing our users for using
>> packs.  If packs aren't fast for users, what are they for?
> 
> They are first in a series of incrementally better formats...

I agree with all this.

> Right now, packs are faster for the very inner most core operations. And
> have considerably better dumb server network performance.

You can be proud of where they've gotten to so far.  So as long as they
don't kill performance on other operations, they're still a really big win.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHUJ3t0F+nu1YWqI0RAiZbAJ0V3/IoETbTH1tVHm45rpK5b2NRXACeLn1V
Ws9T2gbFLPEABeFh4GTd0vw=
=ZFvk
-----END PGP SIGNATURE-----



More information about the bazaar mailing list