view tests/test-convert-hg-svn.t @ 38732:be4984261611

merge: mark file gets as not thread safe (issue5933)

In default installs, this has the effect of disabling the thread-based
worker on Windows when manifesting files in the working directory. My
measurements have shown that with revlog-based repositories, Mercurial
spends a lot of CPU time in revlog code resolving file data. This ends
up incurring a lot of context switching across threads and slows down
`hg update` operations when going from an empty working directory to
the tip of the repo.

On mozilla-unified (246,351 files) on an i7-6700K (4+4 CPUs):

before: 487s wall
after:  360s wall (equivalent to worker.enabled=false)
cpus=2: 379s wall

Even with only 2 threads, the thread pool is still slower.

The introduction of the thread-based worker (02b36e860e0b) states that
it resulted in a "~50%" speedup for `hg sparse --enable-profile` and
`hg sparse --disable-profile`. This disagrees with my measurement
above. I theorize a few reasons for this:

1) Removal of files from the working directory is I/O - not CPU - bound
   and should benefit from a thread pool (unless I/O is insanely fast
   and the GIL release is near instantaneous). So tests like `hg sparse
   --enable-profile` may exercise deletion throughput and aren't good
   benchmarks for worker tasks that are CPU heavy.
2) The patch was authored by someone at Facebook. The results were
   likely measured against a repository using remotefilelog. And I
   believe that revision retrieval during working directory updates with
   remotefilelog will often use a remote store, thus being I/O and not
   CPU bound. This probably resulted in an overstated performance gain.

Since there appears to be a need to enable the thread-based worker with
some stores, I've made the flagging of file gets as thread safe
configurable. I've made it experimental because I don't want to formalize
a boolean flag for this option and because this attribute is best
captured against the store implementation. But we don't have a proper
store API for this yet. I'd rather cross this bridge later.

It is possible there are revlog-based repositories that do benefit from
a thread-based worker. I didn't do very comprehensive testing. If there
are, we may want to devise a more proper algorithm for whether to use
the thread-based worker, including possibly config options to limit the
number of threads to use. But until I see evidence that justifies
complexity, simplicity wins.

Differential Revision: https://phab.mercurial-scm.org/D3963

#require svn svn-bindings

  $ filter_svn_output () {
  >     egrep -v 'Committing|Updating|(^$)' | sed -e 's/done$//' || true
  > }

  $ cat <<EOF >> $HGRCPATH
  > [extensions]
  > convert =
  > mq =
  > EOF

  $ SVNREPOPATH=`pwd`/svn-repo
#if windows
  $ SVNREPOURL=file:///`$PYTHON -c "import urllib, sys; sys.stdout.write(urllib.quote(sys.argv[1]))" "$SVNREPOPATH"`
#else
  $ SVNREPOURL=file://`$PYTHON -c "import urllib, sys; sys.stdout.write(urllib.quote(sys.argv[1]))" "$SVNREPOPATH"`
#endif

  $ svnadmin create "$SVNREPOPATH"
  $ cat > "$SVNREPOPATH"/hooks/pre-revprop-change <<EOF
  > #!/bin/sh
  > 
  > REPOS="$1"
  > REV="$2"
  > USER="$3"
  > PROPNAME="$4"
  > ACTION="$5"
  > 
  > if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi
  > if [ "$ACTION" = "A" -a "$PROPNAME" = "hg:convert-branch" ]; then exit 0; fi
  > if [ "$ACTION" = "A" -a "$PROPNAME" = "hg:convert-rev" ]; then exit 0; fi
  > 
  > echo "Changing prohibited revision property" >&2
  > exit 1
  > EOF
  $ chmod +x "$SVNREPOPATH"/hooks/pre-revprop-change
  $ svn co "$SVNREPOURL" "$SVNREPOPATH"-wc
  Checked out revision 0.
  $ cd "$SVNREPOPATH"-wc
  $ echo a > a
  $ svn add a
  A         a
  $ svn ci -m'added a' a | filter_svn_output
  Adding         a
  Transmitting file data .
  Committed revision 1.
  $ cd ..

initial roundtrip

  $ hg convert -s svn -d hg "$SVNREPOPATH"-wc "$SVNREPOPATH"-hg | grep -v initializing
  scanning source...
  sorting...
  converting...
  0 added a
  $ hg convert -s hg -d svn "$SVNREPOPATH"-hg "$SVNREPOPATH"-wc
  scanning source...
  sorting...
  converting...

second roundtrip should do nothing

  $ hg convert -s svn -d hg "$SVNREPOPATH"-wc "$SVNREPOPATH"-hg
  scanning source...
  sorting...
  converting...
  $ hg convert -s hg -d svn "$SVNREPOPATH"-hg "$SVNREPOPATH"-wc
  scanning source...
  sorting...
  converting...

new hg rev

  $ hg clone "$SVNREPOPATH"-hg "$SVNREPOPATH"-work
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd "$SVNREPOPATH"-work
  $ echo b > b
  $ hg add b
  $ hg ci -mb

adding an empty revision

  $ hg qnew -m emtpy empty
  $ hg qfinish -a
  $ cd ..

echo hg to svn

  $ hg --cwd "$SVNREPOPATH"-hg pull -q "$SVNREPOPATH"-work
  $ hg convert -s hg -d svn "$SVNREPOPATH"-hg "$SVNREPOPATH"-wc
  scanning source...
  sorting...
  converting...
  1 b
  0 emtpy

svn back to hg should do nothing

  $ hg convert -s svn -d hg "$SVNREPOPATH"-wc "$SVNREPOPATH"-hg
  scanning source...
  sorting...
  converting...

hg back to svn should do nothing

  $ hg convert -s hg -d svn "$SVNREPOPATH"-hg "$SVNREPOPATH"-wc
  scanning source...
  sorting...
  converting...

verify which shamap format we are storing and must be able to handle

  $ cat svn-repo-hg/.hg/shamap
  svn:????????-????-????-????-????????????@1 ???????????????????????????????????????? (glob)
  svn:????????-????-????-????-????????????@2 ???????????????????????????????????????? (glob)
  svn:????????-????-????-????-????????????@2 ???????????????????????????????????????? (glob)
  $ cat svn-repo-wc/.svn/hg-shamap
  ???????????????????????????????????????? 1 (glob)
  ???????????????????????????????????????? svn:????????-????-????-????-????????????@2 (glob)
  ???????????????????????????????????????? svn:????????-????-????-????-????????????@2 (glob)