view tests/test-merge-relaxed-block-sync.t @ 52274:6aa4ee2bb128 stable

contrib: add a script to build all of the wheels on macOS

This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`,
except the default pythons to build can be inferred from `setup.py` and/or
`pyproject.toml`, and all use the same configuration.  All we need to do is
force the building of translation files, tell it to skip pypy wheels, and tell
it to build universal2 wheels instead of for the current architecture.

==============================================
Test merge algorithm with "relaxed block sync"
==============================================

Setup
=====

  $ cat >> $HGRCPATH << EOF
  > [experimental]
  > relaxed-block-sync-merge=yes
  > [ui]
  > merge=:merge3
  > EOF
  $ unset HGMERGE

  $ hg init repo
  $ cd repo

  $ m=../scratch
  $ mkdir "$m"

# For the purpose of this test, we use a file [listing] that has one line
# per file of [scratch] directory.
# This way, the patches can be represented as bash scripts.
#
# Adding a line is then just "touch", removing a line is "rm", and
# modifying a line is "echo modfied > file1".

# Make_change takes a "patch script", as described above, and
# produces a file [listing] with the coresponding contents
# past applying the patch to a fixed base state.
  $ make_change() {
  >   cmd=$1
  >    rm -r ../scratch
  >    mkdir ../scratch
  >    (cat listing 2>/dev/null || true) | while IFS=' :' read k v; do echo "$v" > ../scratch/"$k"; done
  >   
  >   (
  >    cd ../scratch
  >    eval "$cmd" >&2
  >    for f in *; do val=$(cat "$f"); printf "$f: $val\n"; done) > listing
  > }

# mk_rev takes a [base] and a patch, and produces a child revision of [base]
# corresponding to that patch.
  $ mk_rev() {
  >   base=$1
  >   cmd=$2
  >   (hg update -C "$base" -q
  >   make_change "$cmd"
  >   (hg commit -qAm _ 2>&1) | grep -v 'commit already existed') >&2
  >   hg log -r . -T '{rev}'
  > }

  $ test() {
  >   cmd1=$1
  >   cmd2=$2
  >   r2=$(mk_rev 0 "$cmd2")
  >   r1=$(mk_rev 0 "$cmd1")
  >   # already at r1
  >   hg merge -q "$r2"
  >   cat listing
  > }

  $ rev0=$(mk_rev 'rev(-1)' 'echo val1 > key1; echo val2 > key2; echo val3 > key3; ')
  $ cat listing
  key1: val1
  key2: val2
  key3: val3

Actual testing
==============

easy merge: no need for relaxed block sync:
-------------------------------------------

  $ test 'echo modified1 > key1' 'echo modified3 > key3'
  key1: modified1
  key2: val2
  key3: modified3

Add adjacent to modify:
-----------------------

  $ test 'echo modified > key3' 'echo val4 > key4'
  key1: val1
  key2: val2
  key3: modified
  key4: val4

Modify adjacent to modify:
--------------------------

  $ test 'echo modified3 > key3' 'echo modified2 > key2'
  key1: val1
  key2: modified2
  key3: modified3

Remove adjacent to modify:
--------------------------

  $ test 'rm key2' 'echo modified > key1'
  key1: modified
  key3: val3

Add adjacent to remove:
-----------------------

  $ test 'rm key2' 'touch key1a'
  key1: val1
  key1a: 
  key3: val3

Remove adjacent to remove:
--------------------------

  $ test 'rm key2' 'rm key1'
  key3: val3

It even works if you're sandwiched between additions above and below:

  $ test 'echo val-changed-3 > key3' 'touch key2a; touch key4'
  key1: val1
  key2: val2
  key2a: 
  key3: val-changed-3
  key4: 

Add adjacent to add:
--------------------

Add adjacent to add is still disallowed because we don't  know what order to add
lines in:

  $ test 'touch key1a' 'touch key1b'
  warning: conflicts while merging listing! (edit, then use 'hg resolve --mark')
  key1: val1
  <<<<<<< working copy:    744662bcc33a - test: _
  key1a: 
  ||||||| common ancestor: b1791e356cd4 - test: _
  =======
  key1b: 
  >>>>>>> merge rev:       06735b47f956 - test: _
  key2: val2
  key3: val3

Add kinda-adjacent to add can still work if there's an
adjacent line that helps resolve the order ambiguity:

  $ test 'touch key1a; rm key2' 'touch key2a'
  key1: val1
  key1a: 
  key2a: 
  key3: val3