There may be a more generic way that would add revset support to more commands
by adding revset support to addbranchrevs(), but given the proximity of the next
code freeze, a minimal change seems like the better choice.
Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
The behaviour is correct but for bad reasons: the repo.set() call in
phase command fails for '-1'. It should be rejected explicitely by phase
boundary commands, sadly this is hard to do because phase changes are
not applied atomically.
Discovery now use an overlay above branchmap to prune invisible "secret"
changeset from branchmap.
To minimise impact on the code during the code freeze, this is achieve by
recomputing non-secret heads on the fly when any secret changeset exists. This
is a computation heavy approach similar to the one used for visible heads. But
few sever should contains secret changeset anyway. See comment in code for more
robust approach.
On local repo the wrapper is applied explicitly while the wire-protocol take
care of wrapping branchmap call in a transparent way. This could be unified by
the Peter Arrenbrecht and Sune Foldager proposal of a `peer` object.
An inappropriate `(+i heads)` may still appear when pushing new changes on a
repository with secret changeset. (see Issue3394 for details)
Before, trying to change the phase of a "public" node to "draft" would result
in:
$ hg phase --draft .
no phases changed
[0]
With this patch:
$ hg phase --draft .
cannot move 1 changesets to a more permissive phase, use --force
no phases changed
[1]
On partial failures, the exit status is now 1 instead of 0 and the number of
changed nodes is displayed while it was only with --verbose. It seems useful to
tell the user that despite the apparent failure, something changed.
$ hg phase --draft '5 or 7'
cannot move 1 changesets to a more permissive phase, use --force
phase changed for 1 changesets
[1]
The outgoing object gains an "excluded" members holding all changesets which
were excluded because there where secret.
The core discovery code now remove secret changeset from discovery by default.
This means that any command relying on discovery will exclude secret changeset.
Most notable one are outgoing and bundle. (But bundle with and explicit
``--base`` still allow to bundle outgoing changeset.
``{phaseidx}`` is providing the phase index as integer. This integer
representation is useful when people need to use the fact that phase are
ordered.
Test keep using the number version for readability purpose.
The bugs seemed to show up when element not in future common changeset should
hold new hold phase data.
The whole phase push machinery was rewritten in the process.
Any secret changesets will be excluded from pull and push. Phase data are
properly synchronized on pull and push if a changeset is seen as secret locally
but is non-secret remote side.
This patch does not handle the case of a changeset secret on remote but known
locally.
