Rev 3906: iter_interesting_nodes really is a culprit causing us to hold on to a record in http://bazaar.launchpad.net/%7Ebzr/bzr/brisbane-core

[John Arbash Meinel]

At http://bazaar.launchpad.net/%7Ebzr/bzr/brisbane-core

------------------------------------------------------------
revno: 3906
revision-id: john at arbash-meinel.com-20090324210500-cxe6eialv4lzed3e
parent: john at arbash-meinel.com-20090324200226-s7xx4fhq2m8mo309
committer: John Arbash Meinel <john at arbash-meinel.com>
branch nick: brisbane-core
timestamp: Tue 2009-03-24 16:05:00 -0500
message:
  iter_interesting_nodes really is a culprit causing us to hold on to a record
  after iterating to the next record.
  We should try to fix that code first.
-------------- next part --------------
=== modified file 'bzrlib/groupcompress.py'
--- a/bzrlib/groupcompress.py	2009-03-24 19:36:34 +0000
+++ b/bzrlib/groupcompress.py	2009-03-24 21:05:00 +0000
@@ -549,7 +549,10 @@
             factory._bytes = None
             # XXX: this is not safe, the smart fetch code requests the content
             #      as both a 'fulltext', and then later on as a
-            #      groupcompress-block
+            #      groupcompress-block. The iter_interesting_nodes code also is
+            #      still buffering multiple records and returning them later.
+            #      So that code would need to be updated to either re-fetch the
+            #      original object, or buffer it somehow.
             # factory._manager = None
         # TODO: Consider setting self._factories = None after the above loop,
         #       as it will break the reference cycle