Merge eats memory

Michael Ellerman michael at
Tue Jun 7 02:14:27 BST 2005

On Mon, 6 Jun 2005 22:54, Aaron Bentley wrote:
> 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?

Yeah it didn't even occur to me that you could "merge" uncommited changes. My 
idea of merge is that you're actually pulling changesets over, so you can't 
merge uncommited stuff 'cause it's not a changeset yet.

> Last-committed revision is generally the 
> desirable thing to merge, but it's harder to do than merging the working
> tree.

I agree. Why is it harder? Because you have to generate the files as they were 
in that revision?

Personally I think it's sub-optimal UI for the most obvious command "bzr 
merge ../other" to not do what I expect, which is merge the last commited 
revision. But then I can't think of a good syntax for saying merge uncommited 

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

Yeah, up until now I've always been merging from the working tree, I don't 
know you needed the "@" syntax on the other branch spec. So it's quite 
possible that the file compares are the problem.


Michael Ellerman
IBM OzLabs

phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the bazaar mailing list