tests/test-issue522.out

localrepo.commit: grab locks before getting the list of files to commit

Somebody may change the dirstate after we've determined the parents of
the working dir and run repo.status, but before we called wlock().

This should also fix issue997, where backout would change a file without
changing its size and then call repo.commit without passing the list of
files. If this happened in less than one second, we wouldn't detect any
file changes - the in-memory dirstate still has the cached stat data for
that file. Grabbing the wlock early causes the dirstate to be
invalidated and we end up reading the dirstate file again, which has
that file marked for lookup (size == -1).

A better fix would be for backout to give repo.commit the exact list of
files, but that'll require some changes to the revert operation.

A significant user-visible change is that the precommit hook is always
run with both locks grabbed - previously, hg commit would run it before
grabbing any locks, but hg import would run it after grabbing locks.

reverting foo
changeset 2:4d9e78aaceee backs out changeset 1:b515023e500e
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
resolving manifests
 overwrite None partial False
 ancestor bbd179dfa0a7 local 71766447bdbb+ remote 4d9e78aaceee
  searching for copies back to rev 1
  unmatched files in local:
   bar
 foo: remote is newer -> g
getting foo
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
n   0         -2 unset               foo
M foo
c6fc755d7e68f49f880599da29f15add41f42f5a 644   foo
   rev    offset  length   base linkrev nodeid       p1           p2
     0         0       5      0       0 2ed2a3912a0b 000000000000 000000000000
     1         5       9      1       1 6f4310b00b9a 2ed2a3912a0b 000000000000
     2        14       5      2       2 c6fc755d7e68 6f4310b00b9a 000000000000