[merge] change commit to use update_to_one_parent_via_delta; other fixes

Ian Clatworthy ian.clatworthy at internode.on.net
Mon Oct 15 07:14:54 BST 2007


Martin Pool wrote:

bb: approve

>> Hmm. This *feels* wrong to me: always returning a delta even when the
>> old path and the new path are the same. In Robert's old code, he
>> explicitly tested for that case and didn't bother with a delta when
>> encountered. Given this change is the essence of this fix, I think
>> we need a clear comment immediately before we set the delta,
>> explaining that we still need a delta because ie has an updated
>> entry (including an updated rev-no).
> 
> I think it's right because we can still update entries that haven't moved.

What I was trying to get at was that the 'delta' accumulated in
commit.py will vary in both size and detail according to the nuances of
the repository. It's therefore not a logical delta and that feels a
little strange.

Robert pointed out on IRC that it won't be anyway and that additional
refactoring would be needed. I'm +1 on the change - just trying to
explain why it felt wrong.

> I measured the performance again: it's about 6% slower than without
> update_etc, which is precisely accounted for by the extra time to do
> _get_inventory and apply_delta.  So for the moment I'm not enabling
> that change but would like to merge in the rest.

Sounds good.

> This update eliminates an unnecessary iteration of the inventory when
> handling deletions, which cuts about 15% off the commit time in a
> 50kfile tree after a deletion has occurred.

Cool.

Ian C.



More information about the bazaar mailing list