testlib: enable rebase and obsolete for easier testing

Initial dumb version of topics.

serveronly: deduplicate code with the main evolve extension Now that 'serveonly' is a sub module of evolve. We can access its content in evolve. As a result we stop duplicating code all common parts are defined in the 'serveronly' module and imported by evolve when needed.

serveronly: clean up imports remove unused one and arrange them

compat: just use '_callcompressable' That API is available in all version we supports.

compat: drop bookmark compatibility layer All the version we now supports have the 'new' API.

compat: drop compat for older wireproto implementation We only support Mercurial version with these attributes.

compat: always use the strip revset from core We only support versions that defines it.

compat: drop support for ancestral pushop object Pushoperation object have a 'cgresult' attribute in all the versions we support.

compat: drop compatibility layer around update We now support only versions with the new API.

compat: drop compatibility layer for 'tryimportone' Return is now homogeneous for all the version we support.

compat: drop superfluous summary output All versions we support issues this output.

compat: drop compatibility layer around memctx The version we support all have the same API now.

compat: drop handling of ancestral 'helploader' caller We only support recent only version on Mercurial now.

compat: drop hack around a 'graft' signature change We only support recent only version of Mercurial now.

evolve: proactively detect bad version early The extensions have been providing such error to the user for some time. So we keep this explicit check (instead of some later errors). The check is update to match out new version constraint.

evolve: drop support for version older than 3.8 The support for 'hgext3rd' was introduced in 3.8. Dropping support for older version seems reasonable.

evolve: cleanup imports Just rearrange imports to a new/clearer style.

merge with stable

merge with mercurial-3.5

merge with mercurial-3.6

merge with mercurial-3.7

merge with mercurial-3.8

merge with mercurial-3.9

merge with mercurial-4.0

merge future 5.6.1

Added tag 5.6.1 for changeset 70694b2621ba

update debian changelog

evolve: extend API fix from 25254b2f8116 to another relevant case For some reason, only part of this API change got fixes. Test did not caught this because 'False' is a valid revision number (0) and update force did not mind using it as an ancestors. The API changed in Mercurial 43c00ca887d1

hgext3rd: drop the last remains of hgext3rd Not that all extensions as moved, we can drop the directory.

hgext3rd: move 'obsolete' as 'evolve.legacy' We move that last extension. It seems like we could use the repo upgrade framework for this, but this is another adventure.

hgext3rd: move 'drophack' as 'evolve.hack.drophack' Yet another extension migrating. Ideally we would implement stripping obsolescence marker in code soon and be able to dispose of this extensions directly. In the mean time this goes into the "hack" namespace.

hgext3rd: move 'simple4server' as 'evolve.serveronly' We also more the server only extension into hgext3rd. We makes it a python sub-module of evolve for two reasons: * less polution in the hgext3rd namespace, * this make it possible to share the code between 'evolve' and 'evolve.serveronly' instead of duplicating it. note that we now install the extension too

hgext3rd: move 'directaccess' and 'inhibit' in 'evolve.hack' We move them in the 'hgext3rd' package. In the same move we put them under the 'evolve' package for clarity. We use a sub-package 'hack' to make their status clearer.

evolve: move the extensions to 'hgext3rd' We have the 'hgext3rd' as the official place for extension for some time now. We start the big migration. This might break some people setup but this is a necessary step to have evolve easily available through pip.

extensions: drop the old 'pushexperiment' extension This extensions predate bundle-2 and their have not been any reason to use it for years.

merge with stable

Update tag 5.6.0 for changeset e7b6e9c4a5d4 There was a small error in the README. The previous tag is fresh and the announcement was sent yet. So I'm exceptionally overwriting the tag.

fix release date in the Readme, Copy paste error :-/

reopen the default branch

merge with 5.6.0 no extra changes were needed from the mercurial-3.5 branch.

merge with 5.6.0 no extra changes were needed form the mercurial-3.6 branch.

merge with 5.6.0 No extra changes were needed from the mercurial-3.7 branch.

merge with 5.6.0 Not extra change were needed from the mercurial-3.8 branch

merge with 5.6.0 A minor one line conflict on test output were encountered.

merge with 5.6.0 No extra changes needed from the 'mercurial-4.' branch.

merge with future 5.6.0 There is only minor test output change, 4.0 do not have the "trouble:" wording in there.

Added tag 5.6.0 for changeset 99ede2d77545

exchange: fix compatibility layer We forgot a return into some compatibility layer. This is now fixed.

open the mercurial-3.9 compat branch

prepare release 5.6.0

debian: fix version format There was a small error in the debian packaging

merge with default to prepare the next version

merge with stable

uncommit: don't lose copy information of remaining files (issue5403) As reported in the issue, "hg uncommit" would lose copy information of the files that remained in the commit. The problem was simply that the a dict of copies was iterated as "src, dst in copies.items()" where it should have been "dst, src ...".

merge with stable

fold: cleanly abort on empty fold set (issue5453) We now handle the empty set case, cleanly aborting instead of crashing with a traceback. The message used match the output of 'hg push' in similar situation.

README: update changelog

fold: require --from flag for folding revisions to working copy It's very easy to think that "hg fold 4::6" will fold exactly those revisions. In reality, it will fold those *and* any revisions between them and the working copy. To prevent users from making that mistake, require the use of a new --from flag for folding revisions from the given set to the working copy. With this change, I'm sure some users will be surprised that the command can not be run without either --from or --exact, but at least the consequences will be smaller (the command simply aborts and the user can try again).

fold: use 'fold', not 'touch', for transaction description