computing the resulting inventory from the merge changeset

[Robert Collins]

On Thu, 2005-12-15 at 11:32 +0100, 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.

That makes sense to me.
..
> > equality checking should always be done via __eq__.
> 
> Yes, and this is not full equality checking: it is equality in the
> sense of what regen_inventory is computing, and that involves only a
> subset of the available attributes.  Also, it is much preferable if
> debugging code does not chance inadvertantly changing object semantics.
> Redefining equality might very well have unexpected consequences ;-)

well the name should be changed then ;). if its not testing equality, is
it testing 'non content equality' ? or '...' ?

Rob



-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051220/2fe1ba10/attachment.pgp