view tests/test-issue1438.t @ 17670:9dbd5fa6d301

filter: `updatebranchcache` during `addchangegroup` instead of after lock

The forced recomputation of the branch cache was introduced by `ee317dbfb9d0`.
Back there, `addchangegroup` did not handle any lock logic.

Later `ee1ed6afac21` introduced lock logic to `addchangegroup`. Its description
does not explain why the `updatebranchcache` call is made outside locking. I
believe that the lock was released there because it fit well with the transaction
release already in the code.

Finally `926a06f7a353` moved all "unlocked" code of `addchangegroup` to an
`repo._afterlock` callback.

I do not think that the call to `updatebranchcache()` requires to be done
outside locking. That may even be a bad idea to do so. Bringing this call back
in the `addchangegroup` function makes the flow simpler and eases the following
up changelog level filtering business.

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

  $ "$TESTDIR/hghave" symlink || exit 80

  $ hg init

  $ ln -s foo link
  $ hg add link
  $ hg ci -mbad link
  $ hg rm link
  $ hg ci -mok
  $ hg diff -g -r 0:1 > bad.patch

  $ hg up 0
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg import --no-commit bad.patch
  applying bad.patch

  $ hg status
  R link
  ? bad.patch