I'm not sure if this is a realistic problem, but doing this avoids
some pretty awful test failures on Python 3, and it looks like it
should be harmless.
Differential Revision: https://phab.mercurial-scm.org/D274
Add a closest argument to successorssets changing the definition of latest
successors.
With "closest=false" (current behavior), latest successors are "leafs" on the
obsmarker graph. They don't have any successor and are known locally.
With "closest=true", latest successors are the closest locally-known
changesets that are visible in the repository or repoview. Closest successors
can be then obsolete, orphan.
This will be used in a later patch to show the closest successor of
changesets with the successorssets template.
Clarify successorssets documentation before we start updating the main function.
This patch serie will introduce the successorssets template, the opposite of
predecessor templates.
Successors will use successorssets function and requires some improvement so
before doing that, we clean up successorssets a bit.
This is a first basic visible usage of the changes tracking in the transaction.
We adds a new function computing the pre-existing changesets obsoleted by a
transaction and a transaction call back displaying this information.
Example output:
added 1 changesets with 1 changes to 1 files (+1 heads)
3 new obsolescence markers
obsoleted 1 changesets
The goal is to evolve the transaction summary into something bigger, gathering
existing output there and adding new useful one. This patch is a good first step
on this road. The new output is basic but give a user to the content of
tr.changes['obsmarkers'] and give an idea of the new options we haves. I expect
to revisit the message soon.
The caller recording the transaction summary should also be moved into a more
generic location but further refactoring is needed before it can happen.
Add a 'predecessors' template that returns the list of all closest known
predecessors for a changectx. The elements of the list are row changectx node id
formatted by default as short nodes.
The "closest predecessors" are the first locally known revisions encountered
while, walking predecessors markers. For example:
1) If a (A, (B)) markers exists and both A and B are locally known A is a
closest predecessors of B.
2) If a (A, (B)) and (B, (C)) markers exists and only A and C are known
locally, A will be the closest precursors of C.
This logic respect repository filtering. So hidden revision will be skipped by
this logic unless --hidden is specified. Since we only display the visible
predecessors, this template will not display anything in most case. It makes a
good candidate for inclusion in the default log output.
I added a new test-file for testing the precursors in various scenarios. This
test file will also be used for the successors template.
A new "obsutil" module has been added to start gathering utility function
outside of the large obsolete.py module.
