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.
#!/bin/rc
# 9diff - Mercurial extdiff wrapper for diff(1)
rfork e
fn getfiles {
cd $1 &&
for(f in `{du -as | awk '{print $2}'})
test -f $f && echo `{cleanname $f}
}
fn usage {
echo >[1=2] usage: 9diff [diff options] parent child root
exit usage
}
opts=()
while(~ $1 -*){
opts=($opts $1)
shift
}
if(! ~ $#* 3)
usage
# extdiff will set the parent and child to a single file if there is
# only one change. If there are multiple changes, directories will be
# set. diff(1) does not cope particularly with directories; instead we
# do the recursion ourselves and diff each file individually.
if(test -f $1)
diff $opts $1 $2
if not{
# extdiff will create a snapshot of the working copy to prevent
# conflicts during the diff. We circumvent this behavior by
# diffing against the repository root to produce plumbable
# output. This is antisocial.
for(f in `{sort -u <{getfiles $1} <{getfiles $2}}){
file1=$1/$f; test -f $file1 || file1=/dev/null
file2=$3/$f; test -f $file2 || file2=/dev/null
diff $opts $file1 $file2
}
}
exit ''