convert: process splicemap in sorted order

mq: stabilize update after strip of parent revision Strip will (if it updates) update to the parent of revs[0], where revs are the roots of the tree that is stripped. When revs was list(set) it was thus undefined which root parent it would update to. With sorted(set) it is at least stable what it updates to. (But it is very possible that another more useful and predictable behaviour could be defined ... such as updating to the tip-most surviving wd ancestor.)

histedit: process bookmarks in sorted order

churn: sort users with same churn by name This makes the output order well-defined and improves code readability.

largefiles: upload files in sorted order

hgweb: generate query strings with parameters sorted by key

identity: report bookmarks sorted

obsolete: process markers in a stable order Using set iteration order gave unstable debugsuccessorssets output with PYTHONHASHSEED=random.

subrepos: process subrepos in sorted order Add sorted() in places found by testing with PYTHONHASHSEED=random and code inspection. An alternative to sprinkling sorted() all over would be to change substate to a custom dict with sorted iterators...

bookmarks: process pulled remote bookmarks in sorted order

copies: report found copies sorted

discovery: process heads in sorted order

merge: process files in sorted order

commandserver: report capabilities sorted