tests/test-bookmarks-strip.t
author Mads Kiilerich <madski@unity3d.com>
Mon, 28 Jan 2013 15:19:44 +0100
branchstable
changeset 18488 a977b42df8b3
parent 17497 b682997d6944
child 21404 ca275f7ec576
permissions -rw-r--r--
largefiles: don't verify largefile hashes on servers when processing statlfile When changesets referencing largefiles are pushed then the corresponding largefiles will be pushed too - unless the target already has them. The client will use statlfile to make sure it only sends largefiles that the target doesn't have. The server would however on every statlfile check that the content of the largefile had the expected hash. What should be cheap thus became an expensive operation that trashed the disk and the cache. Largefile hashes are already checked by putlfile before being stored on the server. A server should thus be able to keep its largefile store free of errors - even more than it can keep revlogs free of errors. Verification should happen when running 'hg verify' locally on the server. Rehashing every largefile on every remote stat is too expensive. Clients will also stat lfiles before downloading them. When the server verified the hash in stat it meant that it had to read the file twice to serve it. With this change the server will assume its own hashes are ok without checking them on every statlfile. Some consequences of this change: - in case of server side corruption the problem will be detected by the existing check on the client side - not on server side - clients that could upload an uncorrupted largefile when pushing will no longer magically heal the server (and break hardlinks) - a client will now only upload its uncorrupted files after the corrupted file has been removed on the server side - client side verify will no longer report corruption in files it doesn't have (Issue3123 discussed related problems - and how they have been fixed.)

  $ 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

  $ 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 ..