bundle: add config option to include phases This adds an experimental.bundle-phases config option to include phase information in bundles. As with the recently added support for bundling obsmarkers, the support for bundling phases is hidden behind the config option until we decide to make a bundlespec v3 that includes phases (and obsmarkers and ...). We could perhaps use the listkeys format for this, but that's considered obsolete according to Pierre-Yves. Instead, we introduce a new "phase-heads" bundle part. The new part contains the phase heads among the set of bundled revisions. It does not include those in secret phase; any head in the bundle that is not mentioned in the phase-heads part is assumed to be secret. As a special case, an empty phase-heads part thus means that any changesets should be added in secret phase. (If we ever add a fourth phase, we'll include secret in the part and we'll add a version number.) For now, phases are only included by "hg bundle", and not by e.g. strip and rebase.

bundle2: record changegroup data in 'op.records' (API) When adding support for bundling and unbundling phases, it will be useful to have the list of added changesets. To do that, we return the list from changegroup.apply().

debugcommands: pass part, not read data, into _debugobsmarker() This matches how it's done for _debugchangegroup() and how we will soon do it for _debugphaseheads().

debugcommands: remove unused "all" argument from _debugobsmarkers

dagop: raise ProgrammingError if stopdepth < 0 revset.py should never send such a value.

py3: add utility to forward __str__() to __bytes__() It calls unifromlocal() instead of sysstr() because __bytes__() may contain locale-dependent values such as paths.

share: use dict literal instead of dict(key=value) check-code.py has the rule, but it isn't smart enough to catch this.