Mercurial > hg
view tests/test-merge-internal-tools-pattern.t @ 21934:0cb34b3991f8 stable
largefiles: use "normallookup" on "lfdirstate" while reverting
Before this patch, largefiles gotten from revisions other than the
parent of the working directory at "hg revert" become "clean"
unexpectedly in steps below:
1. "repo.status()" is invoked (for status check before reverting)
1-1 "dirstate" entry for standinfile SF is "normal"-ed
(1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed)
2. "cmdutil.revert()" is invoked
2-1 standinfile SF is updated in the working directory
2-2 "dirstate" entry for SF is NOT updated
3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()")
3-1 largefile LF (for SF) is updated in the working directory
3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2)
3-3 "lfdirstate" entry for LF is "normal"-ed
3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
timestamp of LF is stored into "lfdirstate" file (by 3-3)
(ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 3-3 and 3-4) as "clean".
When largefiles are reverted, they should be "normallookup"-ed
forcibly.
This patch uses "normallookup" on "lfdirstate" while reverting, by
passing "True" to newly added argument "normallookup".
Forcible "normallookup"-ing is not so expensive, because list of
target largefiles is explicitly specified in this case.
This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)
author | FUJIWARA Katsunori <foozy@lares.dti.ne.jp> |
---|---|
date | Wed, 23 Jul 2014 00:10:24 +0900 |
parents | b63f6422d2a7 |
children | ff12a6c63c3d |
line wrap: on
line source
Make sure that the internal merge tools (internal:fail, internal:local, and internal:other) are used when matched by a merge-pattern in hgrc Make sure HGMERGE doesn't interfere with the test: $ unset HGMERGE $ hg init Initial file contents: $ echo "line 1" > f $ echo "line 2" >> f $ echo "line 3" >> f $ hg ci -Am "revision 0" adding f $ cat f line 1 line 2 line 3 Branch 1: editing line 1: $ sed 's/line 1/first line/' f > f.new $ mv f.new f $ hg ci -Am "edited first line" Branch 2: editing line 3: $ hg update 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ sed 's/line 3/third line/' f > f.new $ mv f.new f $ hg ci -Am "edited third line" created new head Merge using internal:fail tool: $ echo "[merge-patterns]" > .hg/hgrc $ echo "* = internal:fail" >> .hg/hgrc $ hg merge 0 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon [1] $ cat f line 1 line 2 third line $ hg stat M f Merge using internal:local tool: $ hg update -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ sed 's/internal:fail/internal:local/' .hg/hgrc > .hg/hgrc.new $ mv .hg/hgrc.new .hg/hgrc $ hg merge 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat f line 1 line 2 third line $ hg stat M f Merge using internal:other tool: $ hg update -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ sed 's/internal:local/internal:other/' .hg/hgrc > .hg/hgrc.new $ mv .hg/hgrc.new .hg/hgrc $ hg merge 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat f first line line 2 line 3 $ hg stat M f Merge using default tool: $ hg update -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ rm .hg/hgrc $ hg merge merging f 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat f first line line 2 third line $ hg stat M f