the inventory must be updated as merge proceeds, not at the end

[Denys Duchier]

John A Meinel <john at arbash-meinel.com> writes:

> I think Aaron Bentley and myself agree with you here. I think the only
> thing we were concerned with is if you actually write out the entire
> inventory after every change. As this gets very expensive.

I have no intention of writing out the inventory during the merge
process - only at the end.

> My idea was to write the .bzr/inventory in a try/finally, so that
> you can move files around, and if you get an exception, you write
> out so that you represent as many of the changes as possible.

Yes, that can be done too.

> I'm not convinced of limbo_put/limbo_get. The merge code already has a
> working temp directory 'bzr-tree-change'. My solution was to actually
> make that directory versioned for the time that it exists.

That's essentially what I did:  I have a temp directory (I chose
.bzr/limbo, but that choice is immaterial) and I have a limbo
inventory.  However, it turns out that a fullblown limbo inventory is
not really useful.

> Oh, and one other thing. I have a small problem with your second test
> case. Specifically, you are merging into a tree which has uncommitted
> changes, which shouldn't even start without --force.
> Second, you are assuming that 'rm foo' means that the file should be
> removed from the inventory.

No I do not assume so.  I was trying to cover the case of a "contents"
deletion that is not also a file_id removal.  The merge code addresses
that case, but it is indeed difficult to exercise because "commit"
assumes that a missing versioned file means that the file has been
implicited removed (personally, I think that's wrong, but that's a
separate argument).  In any case, the example I devised was the only
way I could think off to exercise that corner case.

Cheers,

--Denys