revset: speed up existence checks for ordered filtered sets Previously, calling 'if foo:' on a ordered filtered set would start iterating in whatever the current direction was and return if a value was available. If the current direction was ascending, but the set had a fastdesc available, this meant we did a lot more work than necessary. If this was applied without my previous max/min fixes, it would improve max() performance (this was my first attempt at fixing the issue). Since those previous fixes went in though, this doesn't have a visible benefit in the benchmarks, but it does seem clearly better than it was before so I think it should still go in.

revset: remove existence check from min() and max() min() and max() would first do an existence check. Unfortunately existence checks can be slow in certain situations (like if the smartset is a list, and quickly iterable in both ascending and descending directions, then doing an existence check will start from the bottom, even if you want to check the max()). The fix is to not do the check, and just handle the error if it happens. In a large repo, this speeds up: hg log -r 'max(parents(. + .^) - (. + .^) & ::master)' from 3.5s to 0.85s. That revset is contrived and just for testing. In our real case we used 'bundle()' in place of '. + .^' Interesting perf numbers for the revset benchmarks: max(draft() and ::tip) => 0.027s to 0.0005s max(author(lmoscovicz)) => 2.48s to 0.57s min doesn't show any perf changes, but changing it as well will prevent a perf regression in my next patch. Result from revset benchmark revset #0: draft() and ::tip min max 0) 0.001971 0.001991 1) 0.001965 0.000428 21% revset #1: ::tip and draft() min max 0) 0.002017 0.001912 1) 0.001896 94% 0.000421 22% revset #2: author(lmoscovicz) min max 0) 1.049033 1.358913 1) 1.042508 0.319824 23% revset #3: author(lmoscovicz) or author(mpm) min max 0) 1.042512 1.367432 1) 1.019750 0.327750 23% revset #4: author(mpm) or author(lmoscovicz) min max 0) 1.050135 0.324924 1) 1.070698 0.319913 revset #5: roots((tip~100::) - (tip~100::tip)) min max 0) 0.000671 0.001018 1) 0.000605 90% 0.000946 92% revset #6: roots((0::) - (0::tip)) min max 0) 0.149714 0.152369 1) 0.098677 65% 0.100374 65% revset #7: (20000::) - (20000) min max 0) 0.051019 0.042747 1) 0.035586 69% 0.016267 38%

update: move default destination into a revset This is another step toward having "default" destination more clear and unified. Not all the logic is there because some bookmark related computation happened elsewhere. It will be moved later. The function is private because as for the other ones, cleanup is needed before we can proceed.

merge: move default destination computation in a revset This is another step toward having "default" destination more clear and unified.

mergecmd: simplify conditional The previous if tested the same thing with 'if repo._activebookmark'. We make the if/else logic clearer before a bigger refactoring.

rebase: move destination computation in a revset This is the first step toward making the "default destination" logic more clear and unified. The revset is private because I'm happy to delay the bikeshedding until after the clean up happened.

debian: include bash completions in mercurial-common

debian: install hgk as part of mercurial-common (issue4829) Leaving the hgk binary in /usr/bin causes some lintian warnings, and downstream packages poke it in /usr/share/mercurial, so we'll just stash it in there. Rather than patch hgk.py as part of the Mercurial install, just drop a config file in /etc/mercurial/hgrc.d that points to the installed hgk.

debian: install config files as part of mercurial-common Future patches will start putting config files in /etc/mercurial/, this just installs them.

debian: configuration so that cacerts is properly loaded This will be included in the mercurial-common package in a followup patch.

debian: install hg-ssh to /usr/bin just like downstream

highlight: remove temporary hack to overwrite repo.getcwd Now hgweb does it globally.

hgweb: overwrite cwd to resolve file patterns relative to repo (issue4568) It's useless to handle file patterns as relative to the cwd of the server process. The only sensible way in hgweb is to resolve paths relative to the repository root. It seems dirstate.getcwd() isn't used to get a real file path, so this patch won't cause problem.

dirstate: state that getcwd() shouldn't be used to get real file path hgweb will force it to be '' so that file patterns can be resolved relative to the repository root. I want to clarify that is correct.