topicmap: massive rework Massively rework the way we build and use topicmap. This bring massive performance benefit. Topic map use to be a fully independant thing that we would switch on and off globaly. The caching on disk was broken so the performance were atrocious. Intead, now the topic are inherited from the 'immutable' map. We gave up on storing them on disk for now since the mutable set is usually small enough. The activation is done by hacking new "filter" on the repository and detection when they are one. This is hacky but core is hard to wrap here. Overall this whole wrapping is really scary and we should massage core API to help it.

topic: use the 'topic' revset in namespace This revset performance just got improved.

topic-revset: update the revset to no longer build changectx Atribute access is expensive, and changectx are very expensive to build, so we skip these for better performance. Before: ! wall 0.012195 comb 0.020000 user 0.020000 sys 0.000000 (best of 217) After: ! wall 0.008816 comb 0.010000 user 0.010000 sys 0.000000 (best of 303) (Before this changeset parent) ! wall 0.213261 comb 0.210000 user 0.210000 sys 0.000000 (best of 45)

topic-revset: changectx creation in the revset The current mutability filter is very expensive, we use a more direct and efficent way to do so: Before: ! wall 0.213261 comb 0.210000 user 0.210000 sys 0.000000 (best of 45) After: ! wall 0.012195 comb 0.020000 user 0.020000 sys 0.000000 (best of 217)

topics: add some noise to rewrittent changeset to prevent hash cycle If we have a changeset with topic `x`, we change it's topic to `y`, fine. When we change it's topic back again to `x`, we get the hash of the the obsoleted changeset which had the topic `x` initially. The same happens for few more cases like clearing the topic of a changeset which initially had no topic. This approach is influenced from cmdutil.amend and other commands (rebase, histedit, etc…)

topic-change: update the working copy along when changing topic of '.' This avoids leaving the working copy behind, removing another large parts of issue5441.

topic-change: cleanup the locking and transaction mechanism The previous code did not garanted we would release all lock (and was a bit more complicated than needed.

topics: use a dict for successors of changesets produced by topic change This patch adds a dictionary to store the successors of changesets which got obsoleted when we change it's topic. This is an improvement in the fix for issue5441.

topic: further simplify the clear logic We just set 'topic' to None and the rest should follow.

topics: drop the clean argument from _changetopics() After this commit, None will represent that we want to clean the topic.

topics: rename '--change' flag to '--rev' flag The --change flag was used to read a revset of which topic should be changed. In mercurial we use --rev for this type of flag. Now things will work as follows: `hg topics topicname`: It will set the current topic `hg topics topicname --rev revset`: Change topic of all the revs in the revset to topicname Further patches will try to achieve the following: `hg topics --clear --rev revset`: clear topic from all the revisions in the revset `hg topics --clear`: clear the current topic (Current behavior) `hg topics --rev revset`: show topics on the revisions in the revset

topics: factor out the logic to change topic in a new function It will help to refactor and fix bugs. Moreover we can re-use the logic.

obslog: update the readme This is release not worthy

obslog: add a comment about the final new line of descriptions