Skip to content
Snippets Groups Projects
  • Gregory Szorc's avatar
    41263df08109
    wireprotov2: change how revisions are specified to changesetdata · 41263df08109
    Gregory Szorc authored
    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
    41263df08109
    History
    wireprotov2: change how revisions are specified to changesetdata
    Gregory Szorc authored
    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
test-ssh-bundle1.t 17.31 KiB
This test is a duplicate of 'test-http.t' feel free to factor out
parts that are not bundle1/bundle2 specific.

#testcases sshv1 sshv2

#if sshv2
  $ cat >> $HGRCPATH << EOF
  > [experimental]
  > sshpeer.advertise-v2 = true
  > sshserver.support-v2 = true
  > EOF
#endif

  $ cat << EOF >> $HGRCPATH
  > [devel]
  > # This test is dedicated to interaction through old bundle
  > legacy.exchange = bundle1
  > EOF


This test tries to exercise the ssh functionality with a dummy script

creating 'remote' repo

  $ hg init remote
  $ cd remote
  $ echo this > foo
  $ echo this > fooO
  $ hg ci -A -m "init" foo fooO

insert a closed branch (issue4428)

  $ hg up null
  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
  $ hg branch closed
  marked working directory as branch closed
  (branches are permanent and global, did you want a bookmark?)
  $ hg ci -mc0
  $ hg ci --close-branch -mc1
  $ hg up -q default

configure for serving

  $ cat <<EOF > .hg/hgrc
  > [server]
  > uncompressed = True
  > 
  > [hooks]
  > changegroup = sh -c "printenv.py changegroup-in-remote 0 ../dummylog"
  > EOF
  $ cd ..

repo not found error

  $ hg clone -e "\"$PYTHON\" \"$TESTDIR/dummyssh\"" ssh://user@dummy/nonexistent local
  remote: abort: repository nonexistent not found!
  abort: no suitable response from remote hg!
  [255]

non-existent absolute path

#if no-msys
  $ hg clone -e "\"$PYTHON\" \"$TESTDIR/dummyssh\"" ssh://user@dummy//`pwd`/nonexistent local
  remote: abort: repository /$TESTTMP/nonexistent not found!
  abort: no suitable response from remote hg!
  [255]
#endif

clone remote via stream