view tests/test-bisect2 @ 8810:ac92775b3b80

Add patch.eol to ignore EOLs when patching (issue1019)

The intent is to fix many issues involving patching when win32ext is enabled.
With win32ext, the working directory and repository files EOLs are not the same
which means that patches made on a non-win32ext host do not apply cleanly
because of EOLs discrepancies. A theorically correct approach would be
transform either the patched file or the patch content with the
encoding/decoding filters used by win32ext. This solution is tricky to
implement and invasive, instead we prefer to address the win32ext case, by
offering a way to ignore input EOLs when patching and rewriting them when
saving the patched result.

#!/bin/sh

# The tests in test-bisect are done on a linear history.
# Here the following repository history is used for testing:
#
#                     17
#                      |
#               18    16 
#                 \  /
#                  15
#                 /  \
#                /    \
#              10     13
#              / \     |
#             /   \    |  14
#        7   6     9  12 /
#         \ / \    |   |/
#          4   \   |  11
#           \   \  |  /
#            3   5 | /
#             \ /  |/ 
#              2   8
#               \ /
#                1
#                |
#                0

set -e

echo % init
hg init

echo % committing changes
echo > a
echo '0' >> a
hg add a
hg ci -m "0" -d "0 0"
echo '1' >> a
hg ci -m "1" -d "1 0"
echo '2' >> a
hg ci -m "2" -d "2 0"
echo '3' >> a
hg ci -m "3" -d "3 0"
echo '4' >> a
hg ci -m "4" -d "4 0"
# create branch
hg up -r 2
echo '5' >> b
hg add b
hg ci -m "5" -d "5 0"

# merge
hg merge
hg ci -m "merge 4,5" -d "6 0"

# create branch
hg up -r 4
echo '7' > c
hg add c
hg ci -m "7" -d "7 0"

# create branch
hg up -r 1
echo '8' > d
hg add d
hg ci -m "8" -d "8 0"
echo '9' >> d
hg ci -m "9" -d "9 0"

# merge
hg merge -r 6
hg ci -m "merge 6,9" -d "10 0"

# create branch
hg up -r 8
echo '11' > e
hg add e
hg ci -m "11" -d "11 0"
echo '12' >> e
hg ci -m "12" -d "12 0"
echo '13' >> e
hg ci -m "13" -d "13 0"

# create branch
hg up -r 11
echo '14' > f
hg add f
hg ci -m "14" -d "14 0"

# merge
hg up -r 13 -C
hg merge -r 10
hg ci -m "merge 10,13" -d "15 0"
echo '16' >> e
hg ci -m "16" -d "16 0"
echo '17' >> e
hg ci -m "17" -d "17 0"

# create branch
hg up -r 15
echo '18' >> e
hg ci -m "18" -d "18 0"


echo % log
hg log

echo % hg up -C
hg up -C

echo % complex bisect test 1  # first bad rev is 9
hg bisect -r
hg bisect -g 0
hg bisect -b 17   # -> update to rev 6
hg bisect -g      # -> update to rev 13
hg bisect -s      # -> update to rev 10
hg bisect -b      # -> update to rev 8
hg bisect -g      # -> update to rev 9
hg bisect -b

echo % complex bisect test 2  # first good rev is 13
hg bisect -r
hg bisect -g 18
hg bisect -b 1    # -> update to rev 6
hg bisect -s      # -> update to rev 10
hg bisect -b      # -> update to rev 12
hg bisect -b      # -> update to rev 13
hg bisect -g

echo % complex bisect test 3  
# first bad rev is 15 
# 10,9,13 are skipped an might be the first bad revisions as well
hg bisect -r
hg bisect -g 1
hg bisect -b 16   # -> update to rev 6
hg bisect -g      # -> update to rev 13
hg bisect -s      # -> update to rev 10
hg bisect -s      # -> update to rev 12
hg bisect -g      # -> update to rev 9
hg bisect -s      # -> update to rev 15
hg bisect -b

echo % complex bisect test 4
# first good revision is 17
# 15,16 are skipped an might be the first good revisions as well
hg bisect -r
hg bisect -g 17
hg bisect -b 8    # -> update to rev 10
hg bisect -b      # -> update to rev 13
hg bisect -b      # -> update to rev 15
hg bisect -s      # -> update to rev 16
hg bisect -s