view tests/test-merge-remove.t @ 37212:f09a2eab11cf

server: add an error feedback mechanism for when the daemon fails to launch There's a recurring problem on Windows where `hg serve -d` will randomly fail to spawn a detached process. The reason for the failure is completely hidden, and it takes hours to get a single failure on my laptop. All this does is redirect stdout/stderr of the child to a file until the lock file is freed, and then the parent dumps it out if it fails to spawn. I chose to put the output into the lock file because that is always cleaned up. There's no way to report errors after that anyway. On Windows, killdaemons.py is roughly `kill -9`, so this ensures that junk won't pile up. This may end up being a case of EADDRINUSE. At least that's what I saw spit out a few times (among other odd errors and missing output on Windows). But I also managed to get the same thing on Fedora 26 by running test-hgwebdir.t with --loop -j10 for several hours. Running `netstat` immediately after killing that run printed a wall of sockets in the TIME_WAIT state, which were gone a couple seconds later. I couldn't match up ports that failed, because --loop doesn't print out the message about the port that was used. So maybe the fix is to rotate the use of HGPORT[12] in the tests. But, let's collect some more data first.
author Matt Harbison <matt_harbison@yahoo.com>
date Wed, 28 Mar 2018 00:11:09 -0400
parents 41ef02ba329b
children f785073f792c
line wrap: on
line source

  $ hg init

  $ echo foo > foo
  $ echo bar > bar
  $ hg ci -qAm 'add foo bar'

  $ echo foo2 >> foo
  $ echo bleh > bar
  $ hg ci -m 'change foo bar'

  $ hg up -qC 0
  $ hg mv foo foo1
  $ echo foo1 > foo1
  $ hg cat foo >> foo1
  $ hg ci -m 'mv foo foo1'
  created new head

  $ hg merge
  merging foo1 and foo to foo1
  1 files updated, 1 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)

  $ hg debugstate --nodates
  m   0         -2 unset               bar
  m   0         -2 unset               foo1
  copy: foo -> foo1

  $ hg st -q
  M bar
  M foo1


Removing foo1 and bar:

  $ cp foo1 F
  $ cp bar B
  $ hg rm -f foo1 bar

  $ hg debugstate --nodates
  r   0         -1 set                 bar
  r   0         -1 set                 foo1
  copy: foo -> foo1

  $ hg st -qC
  R bar
  R foo1


Re-adding foo1 and bar:

  $ cp F foo1
  $ cp B bar
  $ hg add -v foo1 bar
  adding bar
  adding foo1

  $ hg debugstate --nodates
  n   0         -2 unset               bar
  n   0         -2 unset               foo1
  copy: foo -> foo1

  $ hg st -qC
  M bar
  M foo1
    foo


Reverting foo1 and bar:

  $ hg revert -vr . foo1 bar
  saving current version of bar as bar.orig
  reverting bar
  saving current version of foo1 as foo1.orig
  reverting foo1

  $ hg debugstate --nodates
  n   0         -2 unset               bar
  n   0         -2 unset               foo1
  copy: foo -> foo1

  $ hg st -qC
  M bar
  M foo1
    foo

  $ hg diff

Merge should not overwrite local file that is untracked after remove

  $ rm *
  $ hg up -qC
  $ hg rm bar
  $ hg ci -m 'remove bar'
  $ echo 'memories of buried pirate treasure' > bar
  $ hg merge
  bar: untracked file differs
  abort: untracked files in working directory differ from files in requested revision
  [255]
  $ cat bar
  memories of buried pirate treasure

Those who use force will lose

  $ hg merge -f
  other [merge rev] changed bar which local [working copy] deleted
  use (c)hanged version, leave (d)eleted, or leave (u)nresolved? u
  merging foo1 and foo to foo1
  0 files updated, 1 files merged, 0 files removed, 1 files unresolved
  use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon
  [1]
  $ cat bar
  bleh
  $ hg st
  M bar
  M foo1