view tests/test-batching.py.out @ 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.

== Local
Ready.
Un and Deux
Eins und Zwei
One and Two
Nope
Eins und Zwei
Hello, John Smith
Ready.
Uno und Due

== Remote
Ready.
REQ: foo?one=Vo&two=Efvy
  -> Vo!boe!Efvy
Un and Deux
REQ: bar?b=Fjot&a=[xfj
  -> Fjot!voe![xfj
Eins und Zwei
REQ: batch?cmds=foo:one=Pof,two=Uxp;bar:b=Fjot,a=[xfj
  -> Pof!boe!Uxp;Fjot!voe![xfj
REQ: greet?name=Kpio!Tnjui
  -> Ifmmp-!Kpio!Tnjui
REQ: batch?cmds=bar:b=Vop,a=Evf
  -> Vop!voe!Evf
One and Two
Nope
Eins und Zwei
Hello, John Smith
Ready.
Uno und Due