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