tests/test-issue1877.t

bundle2: don't try to recover from a GeneratorExit (issue4785)

GeneratorExit means the other end of the conversation has already
stopped listening, so don't try and yield out error
information. Instead, just let the GeneratorExit propagate normally.

This should resolve esoteric issues observed with servers that have
aggressive timeouts waiting for data to send to clients logging
internal Python errors[0]. This has been observed with both gunicorn's
gevent worker model and with scm-manager's built-in webserver (which
itself is something sitting inside jetty.)


0: Exception RuntimeError: 'generator ignored GeneratorExit' in <generator object getchunks at 0x7fd2f6c586e0> ignored

http://mercurial.selenic.com/bts/issue1877

  $ hg init a
  $ cd a
  $ echo a > a
  $ hg add a
  $ hg ci -m 'a'
  $ echo b > a
  $ hg ci -m'b'
  $ hg up 0
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg book main
  $ hg book
   * main                      0:cb9a9f314b8b
  $ echo c > c
  $ hg add c
  $ hg ci -m'c'
  created new head
  $ hg book
   * main                      2:d36c0562f908
  $ hg heads
  changeset:   2:d36c0562f908
  bookmark:    main
  tag:         tip
  parent:      0:cb9a9f314b8b
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     c
  
  changeset:   1:1e6c11564562
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     b
  
  $ hg up 1e6c11564562
  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
  (leaving bookmark main)
  $ hg merge main
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)
  $ hg book
     main                      2:d36c0562f908
  $ hg ci -m'merge'
  $ hg book
     main                      2:d36c0562f908

  $ cd ..