view tests/test-bookmarks-strip.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 ca275f7ec576
children e78a80f8f51e
line wrap: on
line source

  $ echo "[extensions]" >> $HGRCPATH
  $ echo "mq=" >> $HGRCPATH

  $ hg init

  $ echo qqq>qqq.txt

rollback dry run without rollback information

  $ hg rollback
  no rollback information available
  [1]

add file

  $ hg add
  adding qqq.txt

commit first revision

  $ hg ci -m 1

set bookmark

  $ hg book test

  $ echo www>>qqq.txt

commit second revision

  $ hg ci -m 2

set bookmark

  $ hg book test2

update to -2 (deactivates the active bookmark)

  $ hg update -r -2
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (leaving bookmark test2)

  $ echo eee>>qqq.txt

commit new head

  $ hg ci -m 3
  created new head

bookmarks updated?

  $ hg book
     test                      1:25e1ee7a0081
     test2                     1:25e1ee7a0081

strip to revision 1

  $ hg strip 1
  saved backup bundle to $TESTTMP/.hg/strip-backup/*-backup.hg (glob)

list bookmarks

  $ hg book
     test                      0:5c9ad3787638
     test2                     0:5c9ad3787638

immediate rollback and reentrancy issue

  $ echo "mq=!" >> $HGRCPATH
  $ hg init repo
  $ cd repo
  $ echo a > a
  $ hg ci -Am adda
  adding a
  $ echo b > b
  $ hg ci -Am addb
  adding b
  $ hg bookmarks markb
  $ hg rollback
  repository tip rolled back to revision 0 (undo commit)
  working directory now based on revision 0

are you there?

  $ hg bookmarks
  no bookmarks set

can we commit? (issue2692)

  $ echo c > c
  $ hg ci -Am rockon
  adding c

can you be added again?

  $ hg bookmarks markb
  $ hg bookmarks
   * markb                     1:fdb34407462c

rollback dry run with rollback information

  $ hg rollback -n
  repository tip rolled back to revision 0 (undo commit)
  $ hg bookmarks
   * markb                     1:fdb34407462c

rollback dry run with rollback information and no commit undo

  $ rm .hg/store/undo
  $ hg rollback -n
  no rollback information available
  [1]
  $ hg bookmarks
   * markb                     1:fdb34407462c

  $ cd ..