view tests/test-bundle2-pushback.t @ 30776:3997edc4a86d

repair: determine what upgrade will do This commit introduces code for determining what actions/improvements an upgrade should perform. The "upgradefindimprovements" function introduces a mechanism to return a list of improvements that can be made to a repository. Each improvement is effectively an action that an upgrade will perform. Associated with each of these improvements is metadata that will be used to inform users what's wrong and what an upgrade will do. Each "improvement" is categorized as a "deficiency" or an "optimization." TBH, I'm not thrilled about the terminology and am receptive to constructive bikeshedding. The main difference between a "deficiency" and an "optimization" is a deficiency is always corrected (if it deviates from the current config) and an "optimization" is an optional action that goes above and beyond to improve the state of the repository (usually by requiring more CPU during upgrade). Our initial set of improvements identifies missing repository requirements, a single, easily correctable problem with changelog storage, and a set of "optimizations" related to delta recalculation. The main "upgraderepo" function has been expanded to handle improvements. It queries for the list of improvements and determines which of them will run based on the current repository state and user I went through numerous iterations of the output format before settling on a ReST-inspired definition list format. (I used bulleted lists in the first submission of this commit and could not get it to format just right.) Even with the various iterations, I'm still not super thrilled with the format. But, this is a debug* command, so that should mean we can refine the output without BC concerns.
author Gregory Szorc <gregory.szorc@gmail.com>
date Sun, 18 Dec 2016 16:51:09 -0800
parents 622782ea9cf3
children 8e6f4939a69a
line wrap: on
line source

  $ cat > bundle2.py << EOF
  > """A small extension to test bundle2 pushback parts.
  > Current bundle2 implementation doesn't provide a way to generate those
  > parts, so they must be created by extensions.
  > """
  > from mercurial import bundle2, pushkey, exchange, util
  > def _newhandlechangegroup(op, inpart):
  >     """This function wraps the changegroup part handler for getbundle.
  >     It issues an additional pushkey part to send a new
  >     bookmark back to the client"""
  >     result = bundle2.handlechangegroup(op, inpart)
  >     if 'pushback' in op.reply.capabilities:
  >         params = {'namespace': 'bookmarks',
  >                   'key': 'new-server-mark',
  >                   'old': '',
  >                   'new': 'tip'}
  >         encodedparams = [(k, pushkey.encode(v)) for (k,v) in params.items()]
  >         op.reply.newpart('pushkey', mandatoryparams=encodedparams)
  >     else:
  >         op.reply.newpart('output', data='pushback not enabled')
  >     return result
  > _newhandlechangegroup.params = bundle2.handlechangegroup.params
  > bundle2.parthandlermapping['changegroup'] = _newhandlechangegroup
  > EOF

  $ cat >> $HGRCPATH <<EOF
  > [ui]
  > ssh = python "$TESTDIR/dummyssh"
  > username = nobody <no.reply@example.com>
  > 
  > [alias]
  > tglog = log -G -T "{desc} [{phase}:{node|short}]"
  > EOF

Set up server repository

  $ hg init server
  $ cd server
  $ echo c0 > f0
  $ hg commit -Am 0
  adding f0

Set up client repository

  $ cd ..
  $ hg clone ssh://user@dummy/server client -q
  $ cd client

Enable extension
  $ cat >> $HGRCPATH <<EOF
  > [extensions]
  > bundle2=$TESTTMP/bundle2.py
  > EOF

Without config

  $ cd ../client
  $ echo c1 > f1
  $ hg commit -Am 1
  adding f1
  $ hg push
  pushing to ssh://user@dummy/server
  searching for changes
  remote: adding changesets
  remote: adding manifests
  remote: adding file changes
  remote: added 1 changesets with 1 changes to 1 files
  remote: pushback not enabled
  $ hg bookmark
  no bookmarks set

  $ cd ../server
  $ hg tglog
  o  1 [public:2b9c7234e035]
  |
  @  0 [public:6cee5c8f3e5b]
  



With config

  $ cd ../client
  $ echo '[experimental]' >> .hg/hgrc
  $ echo 'bundle2.pushback = True' >> .hg/hgrc
  $ echo c2 > f2
  $ hg commit -Am 2
  adding f2
  $ hg push
  pushing to ssh://user@dummy/server
  searching for changes
  remote: adding changesets
  remote: adding manifests
  remote: adding file changes
  remote: added 1 changesets with 1 changes to 1 files
  $ hg bookmark
     new-server-mark           2:0a76dfb2e179

  $ cd ../server
  $ hg tglog
  o  2 [public:0a76dfb2e179]
  |
  o  1 [public:2b9c7234e035]
  |
  @  0 [public:6cee5c8f3e5b]