view tests/test-changelog-exec.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 e6e7ef68c879
children 009d0283de5f
line wrap: on
line source

#require execbit

b51a8138292a introduced a regression where we would mention in the
changelog executable files added by the second parent of a merge. Test
that that doesn't happen anymore

  $ hg init repo
  $ cd repo
  $ echo foo > foo
  $ hg ci -qAm 'add foo'

  $ echo bar > bar
  $ chmod +x bar
  $ hg ci -qAm 'add bar'

manifest of p2:

  $ hg manifest
  bar
  foo

  $ hg up -qC 0
  $ echo >> foo
  $ hg ci -m 'change foo'
  created new head

manifest of p1:

  $ hg manifest
  foo

  $ hg merge
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)
  $ chmod +x foo
  $ hg ci -m 'merge'

this should not mention bar but should mention foo:

  $ hg tip -v
  changeset:   3:c53d17ff3380
  tag:         tip
  parent:      2:ed1b79f46b9a
  parent:      1:d394a8db219b
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  files:       foo
  description:
  merge
  
  

  $ hg debugindex bar
     rev    offset  length  ..... linkrev nodeid       p1           p2 (re)
       0         0       5  .....       1 b004912a8510 000000000000 000000000000 (re)

  $ cd ..