exchange: refactor APIs to obtain bundle data (API) Currently, exchange.getbundle() returns either a cg1unpacker or a util.chunkbuffer (in the case of bundle2). This is kinda OK, as both expose a .read() to consumers. However, localpeer.getbundle() has code inferring what the response type is based on arguments and converts the util.chunkbuffer returned in the bundle2 case to a bundle2.unbundle20 instance. This is a sign that the API for exchange.getbundle() is not ideal because it doesn't consistently return an "unbundler" instance. In addition, unbundlers mask the fact that there is an underlying generator of changegroup data. In both cg1 and bundle2, this generator is being fed into a util.chunkbuffer so it can be re-exposed as a file object. util.chunkbuffer is a nice abstraction. However, it should only be used "at the edges." This is because keeping data as a generator is more efficient than converting it to a chunkbuffer, especially if we convert that chunkbuffer back to a generator (as is the case in some code paths currently). This patch refactors exchange.getbundle() into exchange.getbundlechunks(). The new API returns an iterator of chunks instead of a file-like object. Callers of exchange.getbundle() have been updated to use the new API. There is a minor change of behavior in test-getbundle.t. This is because `hg debuggetbundle` isn't defining bundlecaps. As a result, a cg1 data stream and unpacker is being produced. This is getting fed into a new bundle20 instance via bundle2.writebundle(), which uses a backchannel mechanism between changegroup generation to add the "nbchanges" part parameter. I never liked this backchannel mechanism and I plan to remove it someday. `hg bundle` still produces the "nbchanges" part parameter, so there should be no user-visible change of behavior. I consider this "regression" a bug in `hg debuggetbundle`. And that bug is captured by an existing "TODO" in the code to use bundle2 capabilities.

     1

  $ hg init

     2

     3

  $ echo a > a

     4

  $ hg ci -Ama

     5

  adding a

     6

     7

  $ hg an a

     8

  0: a

     9

    10

  $ hg --config ui.strict=False an a

    11

  0: a

    12

    13

  $ echo "[ui]" >> $HGRCPATH

    14

  $ echo "strict=True" >> $HGRCPATH

    15

    16

  $ hg an a

    17

  hg: unknown command 'an'

    18

  Mercurial Distributed SCM

    19

    20

  basic commands:

    21

    22

   add           add the specified files on the next commit

    23

   annotate      show changeset information by line for each file

    24

   clone         make a copy of an existing repository

    25

   commit        commit the specified files or all outstanding changes

    26

   diff          diff repository (or selected files)

    27

   export        dump the header and diffs for one or more changesets

    28

   forget        forget the specified files on the next commit

    29

   init          create a new repository in the given directory

    30

   log           show revision history of entire repository or files

    31

   merge         merge another revision into working directory

    32

   pull          pull changes from the specified source

    33

   push          push changes to the specified destination

    34

   remove        remove the specified files on the next commit

    35

   serve         start stand-alone webserver

    36

   status        show changed files in the working directory

    37

   summary       summarize working directory state

    38

   update        update working directory (or switch revisions)

    39

    40

  (use 'hg help' for the full list of commands or 'hg -v' for details)

    41

  [255]

    42

  $ hg annotate a

    43

  0: a

    44

    45

should succeed - up is an alias, not an abbreviation

    46

    47

  $ hg up

    48

  0 files updated, 0 files merged, 0 files removed, 0 files unresolved