view tests/test-racy-mutations.t @ 50671:e06d1a779eb6

store: stop relying on a `revlog_type` property

We want to know if a file is related to a revlog, but the rest is dealt with
differently already, so we simplify things further.

as a bonus, this cleanup This provides a small but noticeable  speedup.

The number below use `hg perf::stream-locked-section` to measure the time spend
in the locked section of the streaming clone. Number are run on various
repository and compare different steps.:

1) the effect of this patchs,
2) the effect of the cleanup series,
2) current state compared to because large refactoring.

All benchmarks are run on linux with Python 3.10.7.


### Effect of this patch
# mercurial-2018-08-01-zstd-sparse-revlog
  # benchmark.name         = perf-stream-locked-section
before:   0.030246 seconds
after:    0.029274 seconds   (-3.21%)
# pypy-2018-08-01-zstd-sparse-revlog
before:   0.545012 seconds
after:    0.520872 seconds   (-4.43%)
# netbeans-2018-08-01-zstd-sparse-revlog
before:   2.719939 seconds
after:    2.626791 seconds   (-3.42%)
# mozilla-central-2018-08-01-zstd-sparse-revlog
before:   6.304179 seconds
after:    6.096700 seconds   (-3.29%)
# mozilla-try-2019-02-18-zstd-sparse-revlog
before:  14.142687 seconds
after:   13.640779 seconds   (-3.55%)

### Effect of this series

A small but sizeable speedup

# mercurial-2018-08-01-zstd-sparse-revlog
before:  0.031122 seconds
after:   0.029274 seconds   (-5.94%)
# pypy-2018-08-01-zstd-sparse-revlog
before:  0.589970 seconds
after:   0.520872 seconds  (-11.71%)
# netbeans-2018-08-01-zstd-sparse-revlog
before:  2.980300 seconds
after:   2.626791 seconds  (-11.86%)
# mozilla-central-2018-08-01-zstd-sparse-revlog
before:  6.863204 seconds
after:   6.096700 seconds  (-11.17%)
# mozilla-try-2019-02-18-zstd-sparse-revlog
before: 14.921393 seconds
after:  13.640779 seconds   (-8.58%)


### Current state compared to the pre-refactoring state

The refactoring introduced multiple string manipulation and dictionary creation
that seems to induce a signifiant slowdown
Slowdown

# mercurial-2018-08-01-zstd-sparse-revlog
6.4.3:  0.019459 seconds
after:  0.029274 seconds  (+50.44%)
## pypy-2018-08-01-zstd-sparse-revlog
6.4.3:  0.290715 seconds
after:  0.520872 seconds  (+79.17%)
# netbeans-2018-08-01-zstd-sparse-revlog
6.4.3:  1.403447 seconds
after:  2.626791 seconds  (+87.17%)
# mozilla-central-2018-08-01-zstd-sparse-revlog
6.4.3:  3.163549 seconds
after:  6.096700 seconds  (+92.72%)
# mozilla-try-2019-02-18-zstd-sparse-revlog
6.4.3:  6.702184 seconds
after: 13.640779 seconds (+103.53%)

#testcases skip-detection fail-if-detected

Test situations that "should" only be reproducible:
- on networked filesystems, or
- user using `hg debuglocks` to eliminate the lock file, or
- something (that doesn't respect the lock file) writing to the .hg directory
while we're running


Initial setup
-------------

  $ hg init base-repo
  $ cd base-repo

  $ cat > "$TESTTMP_FORWARD_SLASH/waitlock_editor.sh" <<EOF
  >     [ -n "\${WAITLOCK_ANNOUNCE:-}" ] && touch "\${WAITLOCK_ANNOUNCE}"
  >     f="\${WAITLOCK_FILE}"
  >     start=\`date +%s\`
  >     timeout=5
  >     "$RUNTESTDIR_FORWARD_SLASH/testlib/wait-on-file" "\$timeout" "\$f"
  >     if [ \$# -gt 1 ]; then
  >         cat "\$@"
  >     fi
  > EOF

Things behave differently if we don't already have a 00changelog.i file when
this all starts, so let's make one.

  $ echo r0 > r0
  $ hg commit -qAm 'r0'

  $ cd ..
  $ cp -R base-repo main-client
  $ cp -R base-repo racing-client

  $ mkdir sync
  $ EDITOR_STARTED="$TESTTMP_FORWARD_SLASH/sync/.editor_started"
  $ MISCHIEF_MANAGED="$TESTTMP_FORWARD_SLASH/sync/.mischief_managed"
  $ JOBS_FINISHED="$TESTTMP_FORWARD_SLASH/sync/.jobs_finished"

Actual test
-----------

Start an hg commit that will take a while

  $ cd main-client

#if fail-if-detected
  $ cat >> $HGRCPATH << EOF
  > [debug]
  > revlog.verifyposition.changelog = fail
  > EOF
#endif

  $ echo foo > foo
  $ (
  >    unset HGEDITOR;
  >    WAITLOCK_ANNOUNCE="${EDITOR_STARTED}" \
  >    WAITLOCK_FILE="${MISCHIEF_MANAGED}" \
  >    hg commit -qAm 'r1 (foo)' --edit foo \
  >    --config ui.editor="sh $TESTTMP_FORWARD_SLASH/waitlock_editor.sh" \
  >    > .foo_commit_out 2>&1 ;\
  >    touch "${JOBS_FINISHED}"
  > ) &

Wait for the "editor" to actually start
  $ sh "$RUNTESTDIR_FORWARD_SLASH/testlib/wait-on-file" 5 "${EDITOR_STARTED}"


Do a concurrent edition
  $ cd ../racing-client
  $ touch ../pre-race
  $ sleep 1
  $ echo bar > bar
  $ hg --repository ../racing-client commit -qAm 'r2 (bar)' bar
  $ hg --repository ../racing-client debugrevlogindex -c
     rev linkrev nodeid       p1           p2
       0       0 222799e2f90b 000000000000 000000000000
       1       1 6f124f6007a0 222799e2f90b 000000000000

We simulate an network FS race by overwriting raced repo content with the new
content of the files changed in the racing repository

  $ for x in `find . -type f -newer ../pre-race`; do
  >    cp $x ../main-client/$x
  > done
  $ cd ../main-client

Awaken the editor from that first commit
  $ touch "${MISCHIEF_MANAGED}"
And wait for it to finish
  $ WAITLOCK_FILE="${JOBS_FINISHED}" sh "$TESTTMP_FORWARD_SLASH/waitlock_editor.sh"

#if skip-detection
(Ensure there was no output)
  $ cat .foo_commit_out
And observe a corrupted repository -- rev 2's linkrev is 1, which should never
happen for the changelog (the linkrev should always refer to itself).
  $ hg debugrevlogindex -c
     rev linkrev nodeid       p1           p2
       0       0 222799e2f90b 000000000000 000000000000
       1       1 6f124f6007a0 222799e2f90b 000000000000
       2       1 ac80e6205bb2 222799e2f90b 000000000000
#endif

#if fail-if-detected
  $ cat .foo_commit_out
  note: commit message saved in .hg/last-message.txt
  note: use 'hg commit --logfile .hg/last-message.txt --edit' to reuse it
  transaction abort!
  rollback completed
  abort: 00changelog.i: file cursor at position 249, expected 121
And no corruption in the changelog.
  $ hg debugrevlogindex -c
     rev linkrev nodeid       p1           p2
       0       0 222799e2f90b 000000000000 000000000000
       1       1 6f124f6007a0 222799e2f90b 000000000000 (missing-correct-output !)
And, because of transactions, there's none in the manifestlog either.
  $ hg debugrevlogindex -m
     rev linkrev nodeid       p1           p2
       0       0 7b7020262a56 000000000000 000000000000
       1       1 ad3fe36d86d9 7b7020262a56 000000000000
#endif