wireprotov2: change how revisions are specified to changesetdata Right now, we have a handful of arguments for specifying the revisions whose data should be returned. Defining how all these arguments interact when various combinations are present is difficult. This commit establishes a new, generic mechanism for specifying revisions. Instead of a hodgepodge of arguments defining things, we have a list of dicts that specify revision selectors. The final set of revisions is a union of all these selectors. We implement support for specifying revisions based on: * An explicit list of changeset revisions * An explicit list of changeset revisions plus ancestry depth * A DAG range between changeset roots and heads If you squint hard enough, this problem has already been solved by revsets. But I'm reluctant to expose revsets to the wire protocol because that would require servers to implement a revset parser. Plus there are security and performance implications: the set of revision selectors needs to be narrowly and specifically tailored for what is appropriate to be executing on a server. Perhaps there would be a way for us to express the "parse tree" of a revset query, for example. I'm not sure. We can explore this space another time. For now, the new mechanism should bring sufficient flexibility while remaining relatively simple. The selector "types" are prefixed with "changeset" because I plan to add manifest and file-flavored selectors as well. This will enable us to e.g. select file revisions based on a range of changeset revisions. Differential Revision: https://phab.mercurial-scm.org/D4979

     1

  $ . $TESTDIR/wireprotohelpers.sh

     2

     3

  $ hg init server

     4

  $ enablehttpv2 server

     5

  $ cd server

     6

  $ hg debugdrawdag << EOF

     7

  > H I J

     8

  > | | |

     9

  > E F G

    10

  > | |/

    11

  > C D

    12

  > |/

    13

  > B

    14

  > |

    15

  > A

    16

  > EOF

    17

    18

  $ hg phase --force --secret J

    19

  $ hg phase --public E

    20

    21

  $ hg log -r 'E + H + I + G + J' -T '{rev}:{node} {desc} {phase}\n'

    22

  4:78d2dca436b2f5b188ac267e29b81e07266d38fc E public

    23

  7:ae492e36b0c8339ffaf328d00b85b4525de1165e H draft

    24

  8:1d6f6b91d44aaba6d5e580bc30a9948530dbe00b I draft

    25

  6:29446d2dc5419c5f97447a8bc062e4cc328bf241 G draft

    26

  9:dec04b246d7cbb670c6689806c05ad17c835284e J secret

    27

    28

  $ hg serve -p $HGPORT -d --pid-file hg.pid -E error.log

    29

  $ cat hg.pid > $DAEMON_PIDS

    30

    31

All non-secret heads returned by default

    32

    33

  $ sendhttpv2peer << EOF

    34

  > command heads

    35

  > EOF

    36

  creating http peer for wire protocol version 2

    37

  sending heads command

    38

  response: [

    39

    b'\x1dok\x91\xd4J\xab\xa6\xd5\xe5\x80\xbc0\xa9\x94\x850\xdb\xe0\x0b',

    40

    b'\xaeI.6\xb0\xc83\x9f\xfa\xf3(\xd0\x0b\x85\xb4R]\xe1\x16^',

    41

    b')Dm-\xc5A\x9c_\x97Dz\x8b\xc0b\xe4\xcc2\x8b\xf2A'

    42

  ]

    43

    44

Requesting just the public heads works

    45

    46

  $ sendhttpv2peer << EOF

    47

  > command heads

    48

  >     publiconly 1

    49

  > EOF

    50

  creating http peer for wire protocol version 2

    51

  sending heads command

    52

  response: [

    53

    b'x\xd2\xdc\xa46\xb2\xf5\xb1\x88\xac&~)\xb8\x1e\x07&m8\xfc'

    54

  ]

    55

    56

  $ cat error.log