##// END OF EJS Templates
branchmap: server should not advertise secret changeset in branchmap (Issue3303)...
branchmap: server should not advertise secret changeset in branchmap (Issue3303) 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)

File last commit:

r9999:f91e5630 default
r16535:39d1f83e stable
Show More
multirevs.txt
13 lines | 647 B | text/plain | TextLexer
When Mercurial accepts more than one revision, they may be specified
individually, or provided as a topologically continuous range,
separated by the ":" character.
The syntax of range notation is [BEGIN]:[END], where BEGIN and END are
revision identifiers. Both BEGIN and END are optional. If BEGIN is not
specified, it defaults to revision number 0. If END is not specified,
it defaults to the tip. The range ":" thus means "all revisions".
If BEGIN is greater than END, revisions are treated in reverse order.
A range acts as a closed interval. This means that a range of 3:5
gives 3, 4 and 5. Similarly, a range of 9:6 gives 9, 8, 7, and 6.