tests/test-schemes.t
author Matt Harbison <matt_harbison@yahoo.com>
Sat, 24 Mar 2018 01:30:50 -0400
changeset 37104 656ac240f392
parent 27982 bf1d5c223ac0
child 40035 393e44324037
permissions -rw-r--r--
context: skip path conflicts by default when clearing unknown file (issue5776) Prior to adding path conflict checking in 989e884d1be9, the test-audit-path.t tests failed as shown here (but it was globbed away). 989e884d1be9 made it fail with a message about the destination manifest containing a conflict (though the no-symlink case wasn't updated). When the path conflict checking was gated behind an experimental config in 2a774cae3a03^::2a774cae3a03, the update started erroneously succeeding here. It turns out that the child of 989e884d1be9 is the origin of this change when path conflict checking is disabled, as shown by grafting the experimental config range on top of it. What's happening here is merge.batchget() is writing the symlink 'back' to wdir (but as a regular file for the no-symlink case), and then tries to write 'back/test', but calls wctx['back/test'].clearunknown() first. The code that's gated here was removing the newly written 'back' file, allowing 'back/test' to succeed. I tried checking for the dir components of 'back/test' in dirstate, and skipping removal if present. But that didn't work because the dirstate isn't updated after each file is written out. This is the last persistent test failure on Windows, so the testbot should start turning green now. \o/

#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 ..