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

[John A Meinel]

Denys Duchier wrote:
> 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.

Sure. Just be careful because some 'set_inventory' calls do write out
the inventory.

Also, since you aren't writing out the inventory, if you aren't careful
and have 2 WorkingTree objects pointing to the same directory, one of
them won't see the changes.

> 
>> 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.

Well, there is a small difference. Specifically if the directory is in
the working tree, you can version it. You can't version a directory in
.bzr/.
For my idea, while you are doing the merge stuff, you add
bzr-tree-change temporarily. Which means that you only have 1 inventory,
the working inventory. And in the middle of a merge, you add a secret
directory, which will then be removed when you are done. So that if
something got interrupted, you would end up with 'bzr status' showing
that bzr-tree-change was added, and that there were several files
renamed to be underneath it.

> 
>> 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

Well, I think the group decision was that 'a missing versioned file'
should cause commit to fail so the user can decide whether it needs to
be resolved with a 'bzr rm' or a 'bzr mv'.

John
=:->



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051228/09ca40e8/attachment.pgp