test: add a push race case where racing push create a new named branch This is the mirror case from the previos one. We check case where the raced push update a head while the racing push create a new named branch as a children of that updated head.

test: add a push race case where raced push created a new named branch We check case where the raced push create a new branch on the same head updated by the racing push.

test: add a push race case where the racing client create a new head We check case where the raced client push updates an existing head while the racing client push creates a new one.

test: add a push race case where each client replaces a different head We check case where the raced push replace one head while the racing push replaces another unrelated one. That second test also make sure we synchronise all repositories to the same state between tests. That will help us when allowing some sort of concurrent pushes.

test: add a file dedicated to push race between clients There are very few tests around the detection of push race. This file will be dedicated to covering these cases more through fully. We start with a simple case. More complex cases get added in later changesets. My end goal here is to provide a way for server to accept concurrent push as long as they are not touching the same heads. However, I want to buff the test coverage of that code before touching anything.

strip: strip obsmarkers exclusive to the stripped changeset This is it, `hg strip --rev X` will now also remove obsolescence markers exclusive to X. Since a previous changeset, the obsmarkers has been backed up in the strip backup bundle, so it is possible to restore them. Note: stripping obsmarkers means the precursors of the stripped changeset might no longer be obsolete after the strip. Stripping changeset without obsmarkers can be useful when building test case. So It is possible to disable the stripping of obsmarkers using the 'devel.strip-obsmarkers' config option. Test change have been carefully validated.

strip: do not include obsolescence markers for the temporary bundle When stripping, we need to put all non-stripped revisions "above" the stripped ones in a "temporary-bundle" while we strip the targets revision. Then we reapply that bundle to restore these non-stripped revisions (with a new revision numbers). We skip the inclusion of obsolescence markers in that bundle. This is safe since all obsmarkers we plan to strip will be backed-up in the strip backup bundle. Including the markers would create issue in some case were we try to strip a prune markers that is "relevant" to a revision in the "temporary-bundle". (note: we do not strip obsmarkers yet)

exclusive-markers: update the dedicated test with list of exclusive markers We now display data about the "exclusive markers" in the test dedicated to relevant and exclusive markers computation and usage. Each output have been carefully validated

obsolete: add a function to compute "exclusive-markers" for a set of nodes This set will be used to select the obsmarkers to be stripped alongside the stripped changesets. See the function docstring for details. More advanced testing is introduced in the next changesets to keep this one simpler. That extra testing provides more example.

test-obsolete-bundle-strip: check all changesets in the isolated prune case We also want to check the result of the various computations when both changesets are selected (the pruned changesets and its parents).