view tests/test-sparse-verbose-json.t @ 37048:fc5e261915b9

wireproto: require POST for all HTTPv2 requests Wire protocol version 1 transfers argument data via request headers by default. This has historically caused problems because servers institute limits on the length of individual HTTP headers as well as the total size of all request headers. Mercurial servers can advertise the maximum length of an individual header. But there's no guarantee any intermediate HTTP agents will accept headers up to that length. In the existing wire protocol, server operators typically also key off the HTTP request method to implement authentication. For example, GET requests translate to read-only requests and can be allowed. But read-write commands must use POST and require authentication. This has typically worked because the only wire protocol commands that use POST modify the repo (e.g. the "unbundle" command). There is an experimental feature to enable clients to transmit argument data via POST request bodies. This is technically a better and more robust solution. But we can't enable it by default because of servers assuming POST means write access. In version 2 of the wire protocol, the permissions of a request are encoded in the URL. And with it being a new protocol in a new URL space, we're not constrained by backwards compatibility requirements. This commit adopts the technically superior mechanism of using HTTP request bodies to send argument data by requiring POST for all commands. Strictly speaking, it may be possible to send request bodies on GET requests. But my experience is that not all HTTP stacks support this. POST pretty much always works. Using POST for read-only operations does sacrifice some RESTful design purity. But this API cares about practicality, not about being in Roy T. Fielding's REST ivory tower. There's a chance we may relax this restriction in the future. But for now, I want to see how far we can get with a POST only API. Differential Revision: https://phab.mercurial-scm.org/D2837
author Gregory Szorc <gregory.szorc@gmail.com>
date Tue, 13 Mar 2018 11:57:43 -0700
parents 9087f9997f42
children
line wrap: on
line source

test sparse with --verbose and -T json

  $ hg init myrepo
  $ cd myrepo
  $ cat > .hg/hgrc <<EOF
  > [extensions]
  > sparse=
  > strip=
  > EOF

  $ echo a > show
  $ echo x > hide
  $ hg ci -Aqm 'initial'

  $ echo b > show
  $ echo y > hide
  $ echo aa > show2
  $ echo xx > hide2
  $ hg ci -Aqm 'two'

Verify basic --include and --reset

  $ hg up -q 0
  $ hg debugsparse --include 'hide' -Tjson
  [
   {
    "exclude_rules_added": 0,
    "files_added": 0,
    "files_conflicting": 0,
    "files_dropped": 1,
    "include_rules_added": 1,
    "profiles_added": 0
   }
  ]
  $ hg debugsparse --clear-rules
  $ hg debugsparse --include 'hide' --verbose
  removing show
  Profiles changed: 0
  Include rules changed: 1
  Exclude rules changed: 0

  $ hg debugsparse --reset -Tjson
  [
   {
    "exclude_rules_added": 0,
    "files_added": 1,
    "files_conflicting": 0,
    "files_dropped": 0,
    "include_rules_added": -1,
    "profiles_added": 0
   }
  ]
  $ hg debugsparse --include 'hide'
  $ hg debugsparse --reset --verbose
  getting show
  Profiles changed: 0
  Include rules changed: -1
  Exclude rules changed: 0

Verifying that problematic files still allow us to see the deltas when forcing:

  $ hg debugsparse --include 'show*'
  $ touch hide
  $ hg debugsparse --delete 'show*' --force -Tjson
  pending changes to 'hide'
  [
   {
    "exclude_rules_added": 0,
    "files_added": 0,
    "files_conflicting": 1,
    "files_dropped": 0,
    "include_rules_added": -1,
    "profiles_added": 0
   }
  ]
  $ hg debugsparse --include 'show*' --force
  pending changes to 'hide'
  $ hg debugsparse --delete 'show*' --force --verbose
  pending changes to 'hide'
  Profiles changed: 0
  Include rules changed: -1
  Exclude rules changed: 0