[BUG] spurious tree root changes in workingtree2 and 3

Aaron Bentley aaron.bentley at utoronto.ca
Fri Aug 24 03:15:58 BST 2007

Hash: SHA1

Robert Collins wrote:
> Well the CommitBuilder is generated by the repository; so is the content
> of the RevisionTree. So they are coupled already. My iterator is
> encoding the logic used to exclude inventory entries from being given to
> the CommitBuilder at all - we're working towards the delta based commit
> so that a commit of a few files on a large tree does not process O(tree
> entries) data. If root has to be always included, I guess thats ok, but
> it seems wrong to me when we can filter it out earlier.

If you want to peek at repository.suports_rich_root(), you can do it
that way.

>> I don't want the result of revision_tree() to differ between knit1 and
>> knit3 repos.
> They do already though; in a knit3 repo the .revision does not change
> unless the root has actually been modified. Or are you saying that the
> assigned last_modified of a converted knit1 inventory is its revision
> id ?

Yes, I mean "for a given revision".  If that revision is in a knit1
repo, and has also been converted for a knit3 repo, I want consistent
results from both repos.

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list