##// END OF EJS Templates
rhg: add resolve_file_args to path_utils.rs...
rhg: add resolve_file_args to path_utils.rs Extracted logic for resolving `FILE ...` arguments from cat.rs into a new function in path_utils.rs. I plan to use this for rhg annotate. I tried to reuse hg::utils::files::canonical_path instead, but that didn't work. For example it reports a InsideDotHg error for any path containing "..".

File last commit:

r52974:a021da4e default
r53438:f33f37ac tip default
Show More
test-merge-relaxed-block-sync.t
154 lines | 3.4 KiB | text/troff | Tads3Lexer
/ tests / test-merge-relaxed-block-sync.t
==============================================
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