##// END OF EJS Templates
mq: restore _branchtags() fast path (issue3223)...
mq: restore _branchtags() fast path (issue3223) Since a5917346c72e, mq saves the nodeid of the first applied patch to cache/branchheads, which breaks the optimized cache handling introduced in fbf8320f25c8. The problem is the revision being committed is appended to mqrepo.applied after the commit succeeds, which means mqrepo._branchtags() performs a regular update and write the first applied patch to the branch cache. One solution is to set a context variable _committingpatch on the mqrepo while it is committing a patch and to take it in account when deciding to fast-path mqrepo._branchtags(). Not really elegant but it works. The changes to test-mq-caches.t reverse changes introduced by a5917346c72e. The cache should not have been updated with mq records. The changes to test-keyword.t are indirectly caused by a5917346c72e. Reported and analyzed by Yuya Nishihara <yuya@tcha.org> Notes: - qpush still makes a slow path _branchtags() call when checking heads. Maybe this can be optimized. - be careful when merging this patch in default as secretcommit() was renamed newcommit() right after the end of the code freeze.
Patrick Mezard -
r16101:20ad8f05 stable
Show More
Name Size Modified Last Commit Author
/ hgext
convert
highlight
inotify
largefiles
zeroconf
__init__.py Loading ...
acl.py Loading ...
bugzilla.py Loading ...
children.py Loading ...
churn.py Loading ...
color.py Loading ...
eol.py Loading ...
extdiff.py Loading ...
fetch.py Loading ...
gpg.py Loading ...
graphlog.py Loading ...
hgcia.py Loading ...
hgk.py Loading ...
interhg.py Loading ...
keyword.py Loading ...
mq.py Loading ...
notify.py Loading ...
pager.py Loading ...
patchbomb.py Loading ...
progress.py Loading ...
purge.py Loading ...
rebase.py Loading ...
record.py Loading ...
relink.py Loading ...
schemes.py Loading ...
share.py Loading ...
transplant.py Loading ...
win32mbcs.py Loading ...
win32text.py Loading ...