status: support commands.status.relative config When the config is set to true, status output becomes relative to the working directory. This has bugged me since I started using hg and it turns it is sillily simple to support it (unless I missed something, of course). We could also add a --relative flag, but I would personally always want that on, and I haven't heard any use for having it sometimes on, so this patch only lets you enable it via config.

plain: ignore [commands] config We only have commands.{update,rebase}.requiredest so far. We should clearly ignore those two if HGPLAIN is in effect, and it seems like we should ignore any future config that will be added in [commands] since that is about changing the behavior of commands. Thanks to Yuya for suggesting to centralize the code in ui.py. While at it, remove the unnecessary False values passed to ui.configbool() for the aforementioned config options.

changegroup: store old heads as a set Previously, the "oldheads" variable was a list. On a repository at Mozilla with 46,492 heads, profiling revealed that list membership testing was dominating execution time of applying small changegroups. This patch converts the list of old heads to a set. This makes membership testing significantly faster. On the aforementioned repository with 46,492 heads: $ hg unbundle <file with 1 changeset> before: 18.535s wall after: 1.303s Consumers of this variable only check for truthiness (`if oldheads`), length (`len(oldheads)`), and (most importantly) item membership (`h not in oldheads` - which occurs twice). So, the change to a set should be safe and suitable for stable. The practical effect of this change is that changegroup application and related operations (like `hg push`) no longer exhibit an O(n^2) CPU explosion as the number of heads grows.

checkheads: extract obsolete post processing in its own function The checkheads function is long and complex, extract that logic in a subfunction is win in itself. As the comment in the code says, this postprocessing is currently very basic and either misbehave or fails to detect valid push in many cases. My deeper motive for this extraction is to be make it easier to provide extensive testing of this case and strategy to cover them. Final test and logic will makes it to core once done.

tests: make test-simplekeyvaluefile.py py2.6-compatible Python 2.6 unittest.TestCase does not have assertRaisesRegexp.

similar: use cheaper hash() function to test exact matches We just need a hash table {fctx.data(): fctx} which doesn't keep fctx.data() in memory. Let's simply use hash(fctx.data()) to put data out from memory, and manage collided fctx objects by list. This isn't significantly faster than using sha1, but is more correct as we know SHA-1 collision attack is getting practical. Benchmark with 50k added/removed files, on tmpfs: $ hg addremove --dry-run --time -q previous: real 12.420 secs (user 11.120+0.000 sys 1.280+0.000) this patch: real 12.350 secs (user 11.210+0.000 sys 1.140+0.000)

similar: take the first match instead of the last It seems more natural. This makes the next patch slightly cleaner.