view tests/test-basic.t @ 27633:37d7cf569cf3

wireproto: support disabling bundle1 only if repo is generaldelta I recently implemented the server.bundle1* options to control whether bundle1 exchange is allowed. After thinking about Mozilla's strategy for handling generaldelta rollout a bit more, I think server operators need an additional lever: disable bundle1 if and only if the repo is generaldelta. bundle1 exchange for non-generaldelta repos will not have the potential for CPU explosion that generaldelta repos do. Therefore, it makes sense for server operators to continue to allow bundle1 exchange for non-generaldelta repos without having to set a per-repo hgrc option to change the policy depending on whether the repo is generaldelta. This patch introduces a new set of options to control bundle1 behavior for generaldelta repos. These options enable server operators to limit bundle1 restrictions to the class of repos that can be performance issues. It also allows server operators to tie bundle1 access to store format. In many server environments (including Mozilla's), legacy repos will not be generaldelta and new repos will or might be. New repos often aren't bound by legacy access requirements, so setting a global policy that disallows access to new/generaldelta repos via bundle1 could be a reasonable policy in many server environments. This patch makes this policy very easy to implement (modify global hgrc, add options to existing generaldelta repos to grandfather them in).
author Gregory Szorc <gregory.szorc@gmail.com>
date Sun, 20 Dec 2015 11:56:24 -0800
parents 8f88f768e24c
children 3aa50c9d89a0
line wrap: on
line source

Create a repository:

  $ hg config
  defaults.backout=-d "0 0"
  defaults.commit=-d "0 0"
  defaults.shelve=--date "0 0"
  defaults.tag=-d "0 0"
  devel.all-warnings=true
  largefiles.usercache=$TESTTMP/.cache/largefiles (glob)
  ui.slash=True
  ui.interactive=False
  ui.mergemarkers=detailed
  ui.promptecho=True
  $ hg init t
  $ cd t

Make a changeset:

  $ echo a > a
  $ hg add a
  $ hg commit -m test

This command is ancient:

  $ hg history
  changeset:   0:acb14030fe0a
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     test
  

Verify that updating to revision 0 via commands.update() works properly

  $ cat <<EOF > update_to_rev0.py
  > from mercurial import ui, hg, commands
  > myui = ui.ui()
  > repo = hg.repository(myui, path='.')
  > commands.update(myui, repo, rev=0)
  > EOF
  $ hg up null
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
  $ python ./update_to_rev0.py
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg identify -n
  0


Poke around at hashes:

  $ hg manifest --debug
  b789fdd96dc2f3bd229c1dd8eedf0fc60e2b68e3 644   a

  $ hg cat a
  a

Verify should succeed:

  $ hg verify
  checking changesets
  checking manifests
  crosschecking files in changesets and manifests
  checking files
  1 files, 1 changesets, 1 total revisions

At the end...

  $ cd ..