computing the resulting inventory from the merge changeset

[John Arbash Meinel]

duchier at ps.uni-sb.de wrote:
> Robert Collins <robertc at robertcollins.net> writes:
> 
> 
>>What is this used for ? I mean, I see where its used in the code, but
>>whats the win ?
> 
> 
> The main win is that I am starting to understand the issues and how
> the merge code works ;-) In particular, I didn't feel at all confident
> in my ability to perform the BzrCherrypickMetadata brain surgery for
> merge without that understanding.
> 
> I think there is also the potential for code simplification.
> Currently, regen_inventory requires to be handed an auxiliary
> datastructure that describes changes in the form of a mapping from ids
> to paths; it also performs lots of path-related string manipulations.
> 
> My version does not need this auxiliary datastructure: it directly
> uses the changeset that we compute initially.  It also performs no
> string manipulations.
> 
> I think that, instead of the aforementioned auxiliary datatructure,
> apply_changeset should directly return a new inventory describing the
> resulting tree.
> 
> I was also thinking that we may wish to associate metadata properties
> with entries - metadata that perhaps cannot be directly attached to
> files on the filesystem.  If such metadata resides in the inventory,
> then changeset application must indeed compute the resulting inventory
> using the changeset.  As designed, regen_inventory could not do it: or
> at least it would need a more complex auxiliary datastructure; and
> then why not use the merge changeset?
> 
> Btw, I haven't yet had time to look into it, but I have been wondering
> what currently happens, on a system that cannot represent the
> "execute" bit, when we perform a merge that involves a metadata change
> of that bit? regen_inventory will compute an inventory that does not
> reflect this change.
> 
> Using my technique, all metadata changes are reflected in the
> resulting inventory.
> 

This is a very specific use case for Win32 and the executable bit.
Duchier's changes will probably do exactly what I need, which is to set
'executable="yes"' in the working inventory.

Right now the code path goes through apply_changeset, which returns a
dict of changed files, (file_id => path), which goes through
regen_inventory to pick up some extra information. But at that point it
can't pick up the executable bit.

When Aaron and I talked about it, we were thinking that the
ChangesetEntry.apply() functions should actually take a tree rather than
paths, so that each one would apply their changes to both the physical
paths, and to the tree in question.
It means that the working tree inventory would have to also add
bzr-tree-change temporarily, and then as files are moved into there the
inventory itself would be modified.
I would think we should delay writing the working inventory with a
try:finally: so that it doesn't have to get written out after every
operation, but if something fails in the middle, it will still get
written out.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051215/26940242/attachment.pgp