[merge] Make merge internals private

[John Arbash Meinel]

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> 
>>John Arbash Meinel wrote:
>>
>>
>>>>For some reason, merging your branch takes *way* too long. On my fast
>>>>machine it takes 10 minutes to do the merge. On my older machine, I
>>>>killed it after about 15 minutes, but I'll run again to see how long it
>>>>takes. (It seems to spend its time in Weave._extract() considering what
>>>>happened when I canceled it)
>>
>>
>>I've done quite a few uncommits in my time.  Perhaps that's the cause.
>>
>>I've fixed the import problems I could see.  So feel free to integrate it.
>>
>>Aaron
> 
> 
> Well, 'clean-branch --dry-run --all' says that we have 10 unused
> revisions, and 626 unused texts. Which is a bit, but not huge. Not
> enough for me to see a 10 minute merge time.
> 

I have to take that back. --all reports 0 unused revisions on your
branch. It is my branch that has the unused revisions.
And your branch only has 140 unused texts. jam-integration probably has
the other 500 or so.

Having looked at it again (using --lsprof and --profile) the problem is
that the progress bar isn't really indicating what is going on.
The progress bar goes away, which used to mean that it was merging into
your local directory. But now it goes away and is still merging stuff
into weaves.

I really think we need to refactor the progress bar stuff. I would like
to see a nice heirarchial design, which lets us have sub progresses. So
you have the total 'these are the steps it takes to do a merge', and
each one of those can break itself down into specific operations which
take a number of steps.

Oh, and since the inventory.weave merge takes so long, we should have a
progress based on the line it is on. Rather than seeing "inventory.weave
0/1 for 5 minutes".

> I'm still waiting on the 'bzr pull' from your bzr.ab branch (it is still
> on inventory merge), before I can pull it into jam-integration.
> 
> Something seems really wrong for it to be taking this long. But
> whatever, when it finally comes in, I'll merge your changes. I might
> even clean-branch and see what happens.
> 
> John
> =:->

Attached are 2 files, one with --lsprof of doing a full merge. The
second is doing a revert and then merge again. So it is only merging
against the working tree.

I don't really understand the lsprof output yet. It looks like it does
some nice nested trees and such. But it doesn't look like it is sorted
in any reasonable way. Are there any nice viewers for lsprof output?

As a some test points, on my slow machine, doing a merge of bzr.ab took
70 minutes. On my fast machine it took 10 minutes.
After cleaning my jam-integration branch (which frighteningly removed
126 revisions and 1082 texts) and bzr.ab (which removed 148 texts), the
merge took 9.5 minutes. So a little bit faster, but not a lot.

Oh, and jam-integration has so many extra revisions because I sneaked in
some merges against bzr.storage and my encodings branch. They aren't in
the ancestry, but they are in the repository because eventually those
branches will be merged. And I wanted the future merge to be faster.

John
=:->
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: profile-merge-external.txt
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20060124/a0ca9c0b/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: profile-merge-internal.txt
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20060124/a0ca9c0b/attachment-0001.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060124/a0ca9c0b/attachment.pgp