view .hgtags @ 8599:1f706b1b62f3

inotify: server: refactor updatestatus()

* Instead of one entry point, use two entry points, updatefile()
  and deletefile(), both internally calling the helper function _updatestatus
* Do not rely on TypeError to detect the type of oldstatus: use isinstance
* The call updatestatus(wpath, None) in deleted() was a bit particular:
  because no osstat and no newstatus was given, the newstatus was determined
  using the data stored internally. To replace this exact behavior with the
  new code, one would use:
    root, fn = self.split(wpath)
    d = self.dir(self.tree, root)
    self.filedeleted(wpath, d.get(fn))
  This, however, duplicates code with _updatestatus(), which led us to an
  interesting question: why are we basing ourselves on repowatcher data to
  update the status, where everywhere else, we are comparing against dirsate?
  There is no reason to do this, which is why the new code is:
    self.filedeleted(wpath, self.repo.dirstate[wpath])
  Incidentally, after this, the test for issue1371 passes again.

d40cc5aacc31ed673d9b5b24f98bee78c283062c 0.4f
1c590d34bf61e2ea12c71738e5a746cd74586157 0.4e
7eca4cfa8aad5fce9a04f7d8acadcd0452e2f34e 0.4d
b4d0c3786ad3e47beacf8412157326a32b6d25a4 0.4c
f40273b0ad7b3a6d3012fd37736d0611f41ecf54 0.5
0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 0.5b
12e0fdbc57a0be78f0e817fd1d170a3615cd35da 0.6
4ccf3de52989b14c3d84e1097f59e39a992e00bd 0.6b
eac9c8efcd9bd8244e72fb6821f769f450457a32 0.6c
979c049974485125e1f9357f6bbe9c1b548a64c3 0.7
3a56574f329a368d645853e0f9e09472aee62349 0.8
6a03cff2b0f5d30281e6addefe96b993582f2eac 0.8.1
35fb62a3a673d5322f6274a44ba6456e5e4b3b37 0.9
2be3001847cb18a23c403439d9e7d0ace30804e9 0.9.1
36a957364b1b89c150f2d0e60a99befe0ee08bd3 0.9.2
27230c29bfec36d5540fbe1c976810aefecfd1d2 0.9.3
fb4b6d5fe100b0886f8bc3d6731ec0e5ed5c4694 0.9.4
23889160905a1b09fffe1c07378e9fc1827606eb 0.9.5
bae2e9c838e90a393bae3973a7850280413e091a 1.0
d5cbbe2c49cee22a9fbeb9ea41daa0ac4e26b846 1.0.1
d2375bbee6d47e62ba8e415c86e83a465dc4dce9 1.0.2
2a67430f92f15ea5159c26b09ec4839a0c549a26 1.1
3773e510d433969e277b1863c317b674cbee2065 1.1.1
11a4eb81fb4f4742451591489e2797dc47903277 1.1.2
11efa41037e280d08cfb07c09ad485df30fb0ea8 1.2
02981000012e3adf40c4849bd7b3d5618f9ce82d 1.2.1