Merge eats memory

Aaron Bentley aaron.bentley at utoronto.ca
Mon Jun 6 13:54:18 BST 2005


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

Michael Ellerman wrote:
| On Mon, 6 Jun 2005 02:20, Aaron Bentley wrote:
|>Are you merging the working tree or the last-committed revision?  In one
|>case, merge has to read every file in the tree.  In the other, it just
|>compares the text-ids, and only
|
|
| Right. I didn't think you could merge non-commited changes? Guess you
can. It
| still shouldn't be any slower than 'bzr diff ../k2 | patch -p0' should it?

It would make my life easier if you couldn't merge non-committed
changes.  Maybe we shouldn't?  Last-committed revision is generally the
desirable thing to merge, but it's harder to do than merging the working
tree.

But yes, I should be able to get it to roughly the speed of bzr diff, if
I use the statcache (which wasn't available when I started).

|>So try "merge ../other-kernel-tree/@"
|
|
| Jeez that's obvious, why didn't I think of putting an @ there?
|
| That fixes it, only takes about 10 seconds, memory usage looks decent.

Ah.  So it might well have been the file comparisons, then.  I'll have
to test it myself.

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

iD8DBQFCpEd50F+nu1YWqI0RAgw0AJsGVePuc4ENQhKfUfkBJRdpPgnexACfcTwg
+ok3CDIGLr0mTByOoBde0fg=
=JDuY
-----END PGP SIGNATURE-----




More information about the bazaar mailing list