tests/test-patch-offset.t
author Gregory Szorc <gregory.szorc@gmail.com>
Sat, 05 Nov 2016 09:38:07 -0700
branchstable
changeset 30252 4ed8bb8a153f
parent 23749 a387b0390082
child 32958 75be14993fda
permissions -rw-r--r--
hgweb: cache fctx.parents() in annotate command (issue5414) 9c37df347485 introduced a call to fctx.parents() for each line in annotate output. This function call isn't cheap, as it requires linkrev adjustment. Since multiple lines in annotate output tend to belong to the same file revision, a cache of fctx.parents() lookups for each input should be effective in the common case. So we implement one. Since the cache has to precompute parents so an aborted generator doesn't leave an incomplete cache, we could just return a list. However, we preserve the generator for backwards compatibility. The effect of this change when requesting /annotate/96ca0ecdcfa/ browser/locales/en-US/chrome/browser/downloads/downloads.dtd on the mozilla-aurora repo is significant: p1(9c37df347485) 5.5s 9c37df347485: 66.3s this patch: 10.8s We're still slower than before. But only by ~2x instead of ~12x. On the tip revisions of layout/base/nsCSSFrameConstructor.cpp file in the mozilla-unified repo, time went from 12.5s to 14.5s and back to 12.5s. I'm not sure why the mozilla-aurora repo is so slow. Looking at the code of basefilectx.parents(), there is room for further improvements. Notably, we still perform redundant calls to filelog.renamed() and basefilectx._parentfilectx(). And basefilectx.annotate() also makes similar calls, so there is potential for object reuse. However, introducing caches here are not appropriate for the stable branch.


  $ cat > writepatterns.py <<EOF
  > import sys
  > 
  > path = sys.argv[1]
  > patterns = sys.argv[2:]
  > 
  > fp = file(path, 'wb')
  > for pattern in patterns:
  >     count = int(pattern[0:-1])
  >     char = pattern[-1] + '\n'
  >     fp.write(char*count)
  > fp.close()
  > EOF

prepare repo

  $ hg init a
  $ cd a

These initial lines of Xs were not in the original file used to generate
the patch.  So all the patch hunks need to be applied to a constant offset
within this file.  If the offset isn't tracked then the hunks can be
applied to the wrong lines of this file.

  $ python ../writepatterns.py a 34X 10A 1B 10A 1C 10A 1B 10A 1D 10A 1B 10A 1E 10A 1B 10A
  $ hg commit -Am adda
  adding a

This is a cleaner patch generated via diff
In this case it reproduces the problem when
the output of hg export does not
import patch

  $ hg import -v -m 'b' -d '2 0' - <<EOF
  > --- a/a	2009-12-08 19:26:17.000000000 -0800
  > +++ b/a	2009-12-08 19:26:17.000000000 -0800
  > @@ -9,7 +9,7 @@
  >  A
  >  A
  >  B
  > -A
  > +a
  >  A
  >  A
  >  A
  > @@ -53,7 +53,7 @@
  >  A
  >  A
  >  B
  > -A
  > +a
  >  A
  >  A
  >  A
  > @@ -75,7 +75,7 @@
  >  A
  >  A
  >  B
  > -A
  > +a
  >  A
  >  A
  >  A
  > EOF
  applying patch from stdin
  patching file a
  Hunk #1 succeeded at 43 (offset 34 lines).
  Hunk #2 succeeded at 87 (offset 34 lines).
  Hunk #3 succeeded at 109 (offset 34 lines).
  committing files:
  a
  committing manifest
  committing changelog
  created 189885cecb41

compare imported changes against reference file

  $ python ../writepatterns.py aref 34X 10A 1B 1a 9A 1C 10A 1B 10A 1D 10A 1B 1a 9A 1E 10A 1B 1a 9A
  $ diff aref a

  $ cd ..