tests/test-check-commit.t
author Pierre-Yves David <pierre-yves.david@octobus.net>
Tue, 14 Apr 2020 03:16:23 +0200
changeset 44791 b81486b609a3
parent 37816 33817e09c663
permissions -rw-r--r--
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

#require test-repo

Enable obsolescence to avoid the warning issue when obsmarker are found

  $ . "$TESTDIR/helpers-testrepo.sh"

Go back in the hg repo

  $ cd $TESTDIR/..

  $ REVSET='not public() and ::. and not desc("# no-check-commit")'

  $ mkdir "$TESTTMP/p"
  $ REVS=`testrepohg log -r "$REVSET" -T.`
  $ if [ -n "$REVS" ] ; then
  >   testrepohg export --git -o "$TESTTMP/p/%n-%h" -r "$REVSET"
  >   for f in `ls "$TESTTMP/p"`; do
  >      contrib/check-commit < "$TESTTMP/p/$f" > "$TESTTMP/check-commit.out"
  >      if [ $? -ne 0 ]; then
  >          node="${f##*-}"
  >          echo "Revision $node does not comply with rules"
  >          echo '------------------------------------------------------'
  >          cat ${TESTTMP}/check-commit.out
  >          echo
  >     fi
  >   done
  > fi