nodemap: gate the feature behind a new requirement Now that the feature is working smoothly, a question was still open, should we gate the feature behind a new requirement or just treat it as a cache to be warmed by those who can and ignored by other. The advantage of using the cache approach is a transparent upgrade/downgrade story, making the feature easier to move to. However having out of date cache can come with a significant performance hit for process who expect an up to date cache but found none. In this case the file needs to be stored under `.hg/cache`. The "requirement" approach guarantee that the persistent nodemap is up to date. However, it comes with a less flexible activation story since an explicite upgrade is required. In this case the file can be stored in `.hg/store`. This wiki page is relevant to this questions: https://www.mercurial-scm.org/wiki/ComputedIndexPlan So which one should we take? Another element came into plan, the persistent nodemap use the `add` method of the transaction, it is used to keep track of a file content before a transaction in case we need to rollback it back. It turns out that the `transaction.add` API does not support file stored anywhere than `.hg/store`. Making it support file stored elsewhere is possible, require a change in on disk transaction format. Updating on disk file requires… introducing a new requirements. As a result, we pick the second option "gating the persistent nodemap behind a new requirements". Differential Revision: https://phab.mercurial-scm.org/D8417

     1

#

     2

# tcsh completion for Mercurial

     3

#

     4

# This file has been auto-generated by tcsh_completion_build.sh for

     5

# Mercurial Distributed SCM (version 1.7.5+157-8a220ae0b2ba)

     6

#

     7

# Copyright (C) 2005 TK Soh.

     8

#

     9

# This is free software; you can redistribute it and/or modify it under

    10

# the terms of the GNU General Public License as published by the Free

    11

# Software Foundation; either version 2 of the License, or (at your

    12

# option) any later version.

    13

#

    14

    15

complete hg \

    16

  'n/--cwd/d/' 'n/-R/d/' 'n/--repository/d/' \

    17

  'C/-/( -R --repository \

    18

    --cwd \

    19

    -y --noninteractive \

    20

    -q --quiet \

    21

    -v --verbose \

    22

    --config \

    23

    --debug \

    24

    --debugger \

    25

    --encoding \

    26

    --encodingmode \

    27

    --traceback \

    28

    --time \

    29

    --profile \

    30

    --version \

    31

    -h --help)/' \

    32

  'p/1/(add addremove annotate blame archive \

    33

    backout bisect bookmarks branch branches \

    34

    bundle cat clone commit ci \

    35

    copy cp debugancestor debugbuilddag debugcheckstate \

    36

    debugcommands debugcomplete debugdag debugdata debugdate \

    37

    debugfsinfo debugignore debugindex debugindexdot debuginstall \

    38

    debugpushkey debugrebuildstate debugrename debugrevspec debugsetparents \

    39

    debugstate debugsub debugwalk diff export \

    40

    forget grep heads help identify \

    41

    id import patch incoming in \

    42

    init locate log history manifest \

    43

    merge outgoing out parents paths \

    44

    pull push recover remove rm \

    45

    rename move mv resolve revert \

    46

    rollback root serve showconfig debugconfig \

    47

    status st summary sum tag \

    48

    tags tip unbundle update up \

    49

    checkout co verify version)/'

    50