view tests/test-schemes.t @ 39744:52dfa1eb0ad4

shelve: no longer strip internal commit when using internal phase When the internal phase is used, the internal commits we create during shelve will be automatically hidden, and we don't need to strip them. Avoiding strips gives much better performances and is less traumatic for caches. Test changes are all related to revision numbers increasing more quickly since we avoid stripping. At the end of `test-shelve.t` we now need manually strip the shelve-commit in addition to the x.shelve file deletion. This emulates a preexisting shelve after a repository upgrade. Note: The hidden internal commits confuses rebase a bit as shown by a new test added. This will happen when the user have shelve commits on top of a changeset to be rebased. We'll fix this in the next commit. As we still use a backup bundle, rebase can just strip the internal changesets and be fine.
author Boris Feld <boris.feld@octobus.net>
date Wed, 06 Jun 2018 02:31:46 +0200
parents bf1d5c223ac0
children 393e44324037
line wrap: on
line source

#require serve

  $ cat <<EOF >> $HGRCPATH
  > [extensions]
  > schemes=
  > 
  > [schemes]
  > l = http://localhost:$HGPORT/
  > parts = http://{1}:$HGPORT/
  > z = file:\$PWD/
  > EOF
  $ hg init test
  $ cd test
  $ echo a > a
  $ hg ci -Am initial
  adding a

invalid scheme

  $ hg log -R z:z
  abort: no '://' in scheme url 'z:z'
  [255]

http scheme

  $ hg serve -n test -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log
  $ cat hg.pid >> $DAEMON_PIDS
  $ hg incoming l://
  comparing with l://
  searching for changes
  no changes found
  [1]

check that {1} syntax works

  $ hg incoming --debug parts://localhost
  using http://localhost:$HGPORT/
  sending capabilities command
  comparing with parts://localhost/
  query 1; heads
  sending batch command
  searching for changes
  all remote heads known locally
  no changes found
  [1]

check that paths are expanded

  $ PWD=`pwd` hg incoming z://
  comparing with z://
  searching for changes
  no changes found
  [1]

check that debugexpandscheme outputs the canonical form

  $ hg debugexpandscheme bb://user/repo
  https://bitbucket.org/user/repo

expanding an unknown scheme emits the input

  $ hg debugexpandscheme foobar://this/that
  foobar://this/that

expanding a canonical URL emits the input

  $ hg debugexpandscheme https://bitbucket.org/user/repo
  https://bitbucket.org/user/repo

errors

  $ cat errors.log

  $ cd ..