[MERGE] fetch to --dev6-rr should not use deltas

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here is a small change that makes converting to --dev6-rich-root work
(again) for me.

=== modified file 'bzrlib/repofmt/groupcompress_repo.py'
- --- bzrlib/repofmt/groupcompress_repo.py        2009-04-08 16:33:19 +0000
+++ bzrlib/repofmt/groupcompress_repo.py        2009-04-08 16:47:40 +0000
@@ -972,7 +972,7 @@
     # multiple in-a-row (and sharing strings). Topological is better
     # for remote, because we access less data.
     _fetch_order = 'unordered'
- -    _fetch_uses_deltas = True # essentially ignored by the
groupcompress code.
+    _fetch_uses_deltas = False # essentially ignored by the
groupcompress code.
     fast_deltas = True

     def _get_matching_bzrdir(self):

(sorry about the wrapping.) The code in question actually has a comment
about this:

    # Note: We cannot unpack a delta that references a text we haven't
    # seen yet. There are 2 options, work in fulltexts, or require
    # topological sorting. Using fulltexts is more optimal for local
    # operations, because the source can be smart about extracting
    # multiple in-a-row (and sharing strings). Topological is better
    # for remote, because we access less data.
    _fetch_order = 'unordered'
    _fetch_uses_deltas = False # essentially ignored by the
groupcompress code.


Groupcompress ignores deltas, so setting this flag only causes us to
fetch data from non-gc formats in fulltexts.

So why do we need this

1) The 'adapter()' code uses the *target* repository to convert a delta
into a fulltext.
2) If you fetch 'unordered', then you can get a delta for a file before
you get the content of its parent.

So for conversions, we can either chose to set _fetch_order =
'topological', or we can set _fetch_uses_deltas = False. Since
Groupcompress repositories ignore _fetch_uses_deltas, it seemed the
safer thing to set.

Another possibility would be to change the code to buffer these objects
and/or adapt them using the source, rather than the target. However, the
streaming apis pretty much declare that you have to finish the whole
stream before you could request more data, so the length of time we
would buffer is a bit long.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAknc1oAACgkQJdeBCYSNAAM1vwCY+sUQ+eSsXxzM9gUfjP7OMubl
1gCfYKVK6KOriixO7Bk+wfj2NEew3DA=
=ngxl
-----END PGP SIGNATURE-----