Mercurial: Changelog

phases: enforce internal phase support We should not use the internal phase for repository without the requirement. Otherwise, older clients could have a look at the repository and see the internal changesets. For now, we introduce a low-level Programming error, more UI friendly error will be introduced later.

phases: add a repository requirement about internal phase For internal changeset to be properly hidden, the client version needs to support it. So we introduce a new repository requirement that will make sure clients touching a repository that uses internal phase supports the feature.

phases: add an internal phases The phase is meant to be used for internal commit that are a byproduct of command operation (eg:shelve). This changeset focus on getting the most important feature in, more advanced API is to be introduced in later changesets. The phase approach to handle internal has multiple advantages: * simple to implement, reuse optimized code, * fits well with existing phases. We don't want internal changeset to be exchanged or served. * easy to extend to for lifecycle handling. More thinking about internal changeset at https://www.mercurial-scm.org/wiki/InternalsPlan We add this new phases with a high number to leave some room to possible other phases. We also try out playing with the idea of "flag" for phases, each flag would convey a distinct meaning. We can drop the flag idea in the future (keeping the existing numbers). The flag property should still move in a monotonic direction (enabled -> disabled) or be immutable like the "internal" flag. To simplify the addition of this new phase, we introduce many placeholder phases. They are not meant to be used for now. Keeping `allphases` as a list ensure existing algorithm works fine. The full performance impact of adding that many hollow phases is unclear so far. The impact on phase computation is visible but not worrisome. Runnin `hg perfphase` in my mercurial development repository. Before: ! wall 0.001807 comb 0.000000 user 0.000000 sys 0.000000 (median of 1597) after: ! wall 0.001906 comb 0.000000 user 0.000000 sys 0.000000 (median of 1521)

stringutil: teach pprint() to recognize generators Otherwise they get serialized as e.g. <generator object X at 0x7f543d3d68c0> Differential Revision: https://phab.mercurial-scm.org/D4396

commitextras: no need to special case extras=[] Differential Revision: https://phab.mercurial-scm.org/D4405

commitextras: work nicely with other extensions Before this change, it doesn't add these extra fields when loaded alongside another extension that does a bunch of things, including wrapping commit. I did not investigate exactly why, but - the documentation of extensions.wrapfunction says to use subclassing to play nicely with other extensions - using subclassing does make commitextras work when loaded alongside my other extension Differential Revision: https://phab.mercurial-scm.org/D4404

phases: simplify revset in updatephases (Pointed by Yuya Nishihara)

context: use new names for unstable changesets in docstrings Plus slight corrections.

index: embed nodetree in index object to avoid reference cycle Since the index has a reference to a nodetree and the nodetree has a reference back to the index, there is a reference cycle, so the index (and its nodetree) can never be freed. This patch fixes that by making "nodetree" a plan C struct that the index can embed, and also introduces a new "nodetreeObject" that is a Python type wrapping the nodetree struct. Thanks to Yuya for noticing this and for suggesting the solution. All tests passed on the first attempt once it compiled (I guess C is like Haskell in this regard?). Differential Revision: https://phab.mercurial-scm.org/D4372