[MERGE] bzr.ab

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
>>>  1533 Aaron Bentley     2006-02-13
>>>       Test case for discrepancy between fileid_involved and compare_tree
>>> [recommit]
>>>
>>> We probably should put an extra space above FileIdInvolvedBase.
>>> But more importantly, why do you feel that compare_trees() should return
>>> a superset compared with file_id_involved_between_revs? You had a
>>> specific reason, if you can repeat it, it would help me.
> 
> compare_trees is the low-level version of the status command.  It
> compares two trees to see whether their actual contents are different,
> not whether they've had different changes applied.
> 
> That is, if file 'foo' in revision '1' has contents 'bar', and file
> 'foo' in revision '3' has contents 'bar', the two files should compare
> equal.  This is true even if revision '2' had contents 'baz' for file 'foo'.
> 
> Tree comparison operations don't, and IMHO shouldn't, care about
> revision ids, just tree contents.  It would be confusing if bzr status
> reported any differences between revision '1' and revision '3', when the
> text contents (and file layout, etc) of the tree are identical.
> 
> file_id_involved_between_revs is a function to determine which changes
> need to be downloaded when pulling revisions across.  It must care about
> every modification that produces a new revision_id, even those
> modifications that are later reverted (producing yet another new
> revision_id).  So it is proper for it to report 'foo' as an id involved
> between revisions '1' and '3'-- to do otherwise would cause repository
> corruption.
> 

Okay. I actually thought we had the opposite problem. Where you were
saying that compare_trees was returning the superset. I obviously read
the code backwards.

So +1 all around, and merged into jam-integration revno 1531.

>>> After I tried to merge, it turns out that I had already applied your
>>> patch for find-merge-base. So we have a conflict of file ids. Is it okay
>>> if I use my original one, or do you need me to use yours?
> 
> Use yours.  My bad.

This is one of those cases where file_id aliases might be nice. Since
the text is actually identical. So we end up with a file at the same
path, with identical contents. It is also one of the few locations where
git & monotones' "The sha1 is the unique identifier" has some merit.
(Since patching with an external tool results in the same information as
using the scm itself.) Not that it is worth the tradeoffs. :)

John
=:->

> 
> Aaron

-------------- 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/20060213/3af265c6/attachment.pgp