view tests/test-issue1306.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)

http://mercurial.selenic.com/bts/issue1306

Initialize remote repo with branches:

  $ hg init remote
  $ cd remote

  $ echo a > a
  $ hg ci -Ama
  adding a

  $ hg branch br
  marked working directory as branch br
  (branches are permanent and global, did you want a bookmark?)
  $ hg ci -Amb

  $ echo c > c
  $ hg ci -Amc
  adding c

  $ hg log
  changeset:   2:ae3d9c30ec50
  branch:      br
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     c
  
  changeset:   1:3f7f930ca414
  branch:      br
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     b
  
  changeset:   0:cb9a9f314b8b
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     a
  

  $ cd ..

Try cloning -r branch:

  $ hg clone -rbr remote local1
  adding changesets
  adding manifests
  adding file changes
  added 3 changesets with 2 changes to 2 files
  updating to branch br
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg -R local1 parents
  changeset:   2:ae3d9c30ec50
  branch:      br
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     c
  

Try cloning -rother clone#branch:

  $ hg clone -r0 remote#br local2
  adding changesets
  adding manifests
  adding file changes
  added 3 changesets with 2 changes to 2 files
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg -R local2 parents
  changeset:   0:cb9a9f314b8b
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     a
  

Try cloning -r1 clone#branch:

  $ hg clone -r1 remote#br local3
  adding changesets
  adding manifests
  adding file changes
  added 3 changesets with 2 changes to 2 files
  updating to branch br
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg -R local3 parents
  changeset:   1:3f7f930ca414
  branch:      br
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     b