revlog: flag processor
Add the ability for revlog objects to process revision flags and apply
registered transforms on read/write operations.
This patch introduces:
- the 'revlog._processflags()' method that looks at revision flags and applies
flag processors registered on them. Due to the need to handle non-commutative
operations, flag transforms are applied in stable order but the order in which
the transforms are applied is reversed between read and write operations.
- the 'addflagprocessor()' method allowing to register processors on flags.
Flag processors are defined as a 3-tuple of (read, write, raw) functions to be
applied depending on the operation being performed.
- an update on 'revlog.addrevision()' behavior. The current flagprocessor design
relies on extensions to wrap around 'addrevision()' to set flags on revision
data, and on the flagprocessor to perform the actual transformation of its
contents. In the lfs case, this means we need to process flags before we meet
the 2GB size check, leading to performing some operations before it happens:
- if flags are set on the revision data, we assume some extensions might be
modifying the contents using the flag processor next, and we compute the
node for the original revision data (still allowing extension to override
the node by wrapping around 'addrevision()').
- we then invoke the flag processor to apply registered transforms (in lfs's
case, drastically reducing the size of large blobs).
- finally, we proceed with the 2GB size check.
Note: In the case a cachedelta is passed to 'addrevision()' and we detect the
flag processor modified the revision data, we chose to trust the flag processor
and drop the cachedelta.
2017-01-10 19:15:21 +03:00
|
|
|
# Create server
|
|
|
|
$ hg init server
|
|
|
|
$ cd server
|
|
|
|
$ cat >> .hg/hgrc << EOF
|
|
|
|
> [extensions]
|
|
|
|
> extension=$TESTDIR/flagprocessorext.py
|
|
|
|
> EOF
|
|
|
|
$ cd ../
|
|
|
|
|
|
|
|
# Clone server and enable extensions
|
|
|
|
$ hg clone -q server client
|
|
|
|
$ cd client
|
|
|
|
$ cat >> .hg/hgrc << EOF
|
|
|
|
> [extensions]
|
|
|
|
> extension=$TESTDIR/flagprocessorext.py
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
# Commit file that will trigger the noop extension
|
|
|
|
$ echo '[NOOP]' > noop
|
|
|
|
$ hg commit -Aqm "noop"
|
|
|
|
|
|
|
|
# Commit file that will trigger the base64 extension
|
|
|
|
$ echo '[BASE64]' > base64
|
|
|
|
$ hg commit -Aqm 'base64'
|
|
|
|
|
|
|
|
# Commit file that will trigger the gzip extension
|
|
|
|
$ echo '[GZIP]' > gzip
|
|
|
|
$ hg commit -Aqm 'gzip'
|
|
|
|
|
|
|
|
# Commit file that will trigger noop and base64
|
|
|
|
$ echo '[NOOP][BASE64]' > noop-base64
|
|
|
|
$ hg commit -Aqm 'noop+base64'
|
|
|
|
|
|
|
|
# Commit file that will trigger noop and gzip
|
|
|
|
$ echo '[NOOP][GZIP]' > noop-gzip
|
|
|
|
$ hg commit -Aqm 'noop+gzip'
|
|
|
|
|
|
|
|
# Commit file that will trigger base64 and gzip
|
|
|
|
$ echo '[BASE64][GZIP]' > base64-gzip
|
|
|
|
$ hg commit -Aqm 'base64+gzip'
|
|
|
|
|
|
|
|
# Commit file that will trigger base64, gzip and noop
|
|
|
|
$ echo '[BASE64][GZIP][NOOP]' > base64-gzip-noop
|
|
|
|
$ hg commit -Aqm 'base64+gzip+noop'
|
|
|
|
|
|
|
|
# TEST: ensure the revision data is consistent
|
|
|
|
$ hg cat noop
|
|
|
|
[NOOP]
|
|
|
|
$ hg debugdata noop 0
|
|
|
|
[NOOP]
|
|
|
|
|
|
|
|
$ hg cat -r . base64
|
|
|
|
[BASE64]
|
|
|
|
$ hg debugdata base64 0
|
|
|
|
W0JBU0U2NF0K (no-eol)
|
|
|
|
|
|
|
|
$ hg cat -r . gzip
|
|
|
|
[GZIP]
|
|
|
|
$ hg debugdata gzip 0
|
|
|
|
x\x9c\x8bv\x8f\xf2\x0c\x88\xe5\x02\x00\x08\xc8\x01\xfd (no-eol) (esc)
|
|
|
|
|
|
|
|
$ hg cat -r . noop-base64
|
|
|
|
[NOOP][BASE64]
|
|
|
|
$ hg debugdata noop-base64 0
|
|
|
|
W05PT1BdW0JBU0U2NF0K (no-eol)
|
|
|
|
|
|
|
|
$ hg cat -r . noop-gzip
|
|
|
|
[NOOP][GZIP]
|
|
|
|
$ hg debugdata noop-gzip 0
|
|
|
|
x\x9c\x8b\xf6\xf3\xf7\x0f\x88\x8dv\x8f\xf2\x0c\x88\xe5\x02\x00\x1dH\x03\xf1 (no-eol) (esc)
|
|
|
|
|
|
|
|
$ hg cat -r . base64-gzip
|
|
|
|
[BASE64][GZIP]
|
|
|
|
$ hg debugdata base64-gzip 0
|
|
|
|
eJyLdnIMdjUziY12j/IMiOUCACLBBDo= (no-eol)
|
|
|
|
|
|
|
|
$ hg cat -r . base64-gzip-noop
|
|
|
|
[BASE64][GZIP][NOOP]
|
|
|
|
$ hg debugdata base64-gzip-noop 0
|
|
|
|
eJyLdnIMdjUziY12j/IMiI328/cPiOUCAESjBi4= (no-eol)
|
|
|
|
|
|
|
|
# Push to the server
|
|
|
|
$ hg push
|
2017-12-11 06:50:57 +03:00
|
|
|
pushing to $TESTTMP/server
|
revlog: flag processor
Add the ability for revlog objects to process revision flags and apply
registered transforms on read/write operations.
This patch introduces:
- the 'revlog._processflags()' method that looks at revision flags and applies
flag processors registered on them. Due to the need to handle non-commutative
operations, flag transforms are applied in stable order but the order in which
the transforms are applied is reversed between read and write operations.
- the 'addflagprocessor()' method allowing to register processors on flags.
Flag processors are defined as a 3-tuple of (read, write, raw) functions to be
applied depending on the operation being performed.
- an update on 'revlog.addrevision()' behavior. The current flagprocessor design
relies on extensions to wrap around 'addrevision()' to set flags on revision
data, and on the flagprocessor to perform the actual transformation of its
contents. In the lfs case, this means we need to process flags before we meet
the 2GB size check, leading to performing some operations before it happens:
- if flags are set on the revision data, we assume some extensions might be
modifying the contents using the flag processor next, and we compute the
node for the original revision data (still allowing extension to override
the node by wrapping around 'addrevision()').
- we then invoke the flag processor to apply registered transforms (in lfs's
case, drastically reducing the size of large blobs).
- finally, we proceed with the 2GB size check.
Note: In the case a cachedelta is passed to 'addrevision()' and we detect the
flag processor modified the revision data, we chose to trust the flag processor
and drop the cachedelta.
2017-01-10 19:15:21 +03:00
|
|
|
searching for changes
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 7 changesets with 7 changes to 7 files
|
|
|
|
|
|
|
|
# Initialize new client (not cloning) and setup extension
|
|
|
|
$ cd ..
|
|
|
|
$ hg init client2
|
|
|
|
$ cd client2
|
|
|
|
$ cat >> .hg/hgrc << EOF
|
|
|
|
> [paths]
|
|
|
|
> default = $TESTTMP/server
|
|
|
|
> [extensions]
|
|
|
|
> extension=$TESTDIR/flagprocessorext.py
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
# Pull from server and update to latest revision
|
|
|
|
$ hg pull default
|
2017-12-11 06:50:57 +03:00
|
|
|
pulling from $TESTTMP/server
|
revlog: flag processor
Add the ability for revlog objects to process revision flags and apply
registered transforms on read/write operations.
This patch introduces:
- the 'revlog._processflags()' method that looks at revision flags and applies
flag processors registered on them. Due to the need to handle non-commutative
operations, flag transforms are applied in stable order but the order in which
the transforms are applied is reversed between read and write operations.
- the 'addflagprocessor()' method allowing to register processors on flags.
Flag processors are defined as a 3-tuple of (read, write, raw) functions to be
applied depending on the operation being performed.
- an update on 'revlog.addrevision()' behavior. The current flagprocessor design
relies on extensions to wrap around 'addrevision()' to set flags on revision
data, and on the flagprocessor to perform the actual transformation of its
contents. In the lfs case, this means we need to process flags before we meet
the 2GB size check, leading to performing some operations before it happens:
- if flags are set on the revision data, we assume some extensions might be
modifying the contents using the flag processor next, and we compute the
node for the original revision data (still allowing extension to override
the node by wrapping around 'addrevision()').
- we then invoke the flag processor to apply registered transforms (in lfs's
case, drastically reducing the size of large blobs).
- finally, we proceed with the 2GB size check.
Note: In the case a cachedelta is passed to 'addrevision()' and we detect the
flag processor modified the revision data, we chose to trust the flag processor
and drop the cachedelta.
2017-01-10 19:15:21 +03:00
|
|
|
requesting all changes
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 7 changesets with 7 changes to 7 files
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets 07b1b9442c5b:6e48f4215d24
|
revlog: flag processor
Add the ability for revlog objects to process revision flags and apply
registered transforms on read/write operations.
This patch introduces:
- the 'revlog._processflags()' method that looks at revision flags and applies
flag processors registered on them. Due to the need to handle non-commutative
operations, flag transforms are applied in stable order but the order in which
the transforms are applied is reversed between read and write operations.
- the 'addflagprocessor()' method allowing to register processors on flags.
Flag processors are defined as a 3-tuple of (read, write, raw) functions to be
applied depending on the operation being performed.
- an update on 'revlog.addrevision()' behavior. The current flagprocessor design
relies on extensions to wrap around 'addrevision()' to set flags on revision
data, and on the flagprocessor to perform the actual transformation of its
contents. In the lfs case, this means we need to process flags before we meet
the 2GB size check, leading to performing some operations before it happens:
- if flags are set on the revision data, we assume some extensions might be
modifying the contents using the flag processor next, and we compute the
node for the original revision data (still allowing extension to override
the node by wrapping around 'addrevision()').
- we then invoke the flag processor to apply registered transforms (in lfs's
case, drastically reducing the size of large blobs).
- finally, we proceed with the 2GB size check.
Note: In the case a cachedelta is passed to 'addrevision()' and we detect the
flag processor modified the revision data, we chose to trust the flag processor
and drop the cachedelta.
2017-01-10 19:15:21 +03:00
|
|
|
(run 'hg update' to get a working copy)
|
|
|
|
$ hg update
|
|
|
|
7 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
|
|
|
|
# TEST: ensure the revision data is consistent
|
|
|
|
$ hg cat noop
|
|
|
|
[NOOP]
|
|
|
|
$ hg debugdata noop 0
|
|
|
|
[NOOP]
|
|
|
|
|
|
|
|
$ hg cat -r . base64
|
|
|
|
[BASE64]
|
|
|
|
$ hg debugdata base64 0
|
|
|
|
W0JBU0U2NF0K (no-eol)
|
|
|
|
|
|
|
|
$ hg cat -r . gzip
|
|
|
|
[GZIP]
|
|
|
|
$ hg debugdata gzip 0
|
|
|
|
x\x9c\x8bv\x8f\xf2\x0c\x88\xe5\x02\x00\x08\xc8\x01\xfd (no-eol) (esc)
|
|
|
|
|
|
|
|
$ hg cat -r . noop-base64
|
|
|
|
[NOOP][BASE64]
|
|
|
|
$ hg debugdata noop-base64 0
|
|
|
|
W05PT1BdW0JBU0U2NF0K (no-eol)
|
|
|
|
|
|
|
|
$ hg cat -r . noop-gzip
|
|
|
|
[NOOP][GZIP]
|
|
|
|
$ hg debugdata noop-gzip 0
|
|
|
|
x\x9c\x8b\xf6\xf3\xf7\x0f\x88\x8dv\x8f\xf2\x0c\x88\xe5\x02\x00\x1dH\x03\xf1 (no-eol) (esc)
|
|
|
|
|
|
|
|
$ hg cat -r . base64-gzip
|
|
|
|
[BASE64][GZIP]
|
|
|
|
$ hg debugdata base64-gzip 0
|
|
|
|
eJyLdnIMdjUziY12j/IMiOUCACLBBDo= (no-eol)
|
|
|
|
|
|
|
|
$ hg cat -r . base64-gzip-noop
|
|
|
|
[BASE64][GZIP][NOOP]
|
|
|
|
$ hg debugdata base64-gzip-noop 0
|
|
|
|
eJyLdnIMdjUziY12j/IMiI328/cPiOUCAESjBi4= (no-eol)
|
|
|
|
|
|
|
|
# TEST: ensure a missing processor is handled
|
|
|
|
$ echo '[FAIL][BASE64][GZIP][NOOP]' > fail-base64-gzip-noop
|
|
|
|
$ hg commit -Aqm 'fail+base64+gzip+noop'
|
|
|
|
abort: missing processor for flag '0x1'!
|
|
|
|
[255]
|
2017-08-01 02:40:31 +03:00
|
|
|
$ rm fail-base64-gzip-noop
|
revlog: flag processor
Add the ability for revlog objects to process revision flags and apply
registered transforms on read/write operations.
This patch introduces:
- the 'revlog._processflags()' method that looks at revision flags and applies
flag processors registered on them. Due to the need to handle non-commutative
operations, flag transforms are applied in stable order but the order in which
the transforms are applied is reversed between read and write operations.
- the 'addflagprocessor()' method allowing to register processors on flags.
Flag processors are defined as a 3-tuple of (read, write, raw) functions to be
applied depending on the operation being performed.
- an update on 'revlog.addrevision()' behavior. The current flagprocessor design
relies on extensions to wrap around 'addrevision()' to set flags on revision
data, and on the flagprocessor to perform the actual transformation of its
contents. In the lfs case, this means we need to process flags before we meet
the 2GB size check, leading to performing some operations before it happens:
- if flags are set on the revision data, we assume some extensions might be
modifying the contents using the flag processor next, and we compute the
node for the original revision data (still allowing extension to override
the node by wrapping around 'addrevision()').
- we then invoke the flag processor to apply registered transforms (in lfs's
case, drastically reducing the size of large blobs).
- finally, we proceed with the 2GB size check.
Note: In the case a cachedelta is passed to 'addrevision()' and we detect the
flag processor modified the revision data, we chose to trust the flag processor
and drop the cachedelta.
2017-01-10 19:15:21 +03:00
|
|
|
|
|
|
|
# TEST: ensure we cannot register several flag processors on the same flag
|
|
|
|
$ cat >> .hg/hgrc << EOF
|
|
|
|
> [extensions]
|
|
|
|
> extension=$TESTDIR/flagprocessorext.py
|
|
|
|
> duplicate=$TESTDIR/flagprocessorext.py
|
|
|
|
> EOF
|
codemod: join the auto-formatter party
Summary:
Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK **/*.py`.
Then run `arc lint` again so some other autofixers like spellchecker etc. looked
at the code base. Manually accept the changes whenever they make sense, or use
a workaround (ex. changing "dict()" to "dict constructor") where autofix is false
positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less
interesting to fix (hgsubversion tests), or cannot be fixed without breaking
OSS build (FBPYTHON4).
Conflicted linters (test-check-module-imports.t, part of test-check-code.t,
test-check-pyflakes.t) are removed or disabled.
Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed.
An issue of the auto-formatter is lines are no longer guarnateed to be <= 80
chars. But that seems less important comparing with the benefit auto-formatter
provides.
As we're here, also remove test-check-py3-compat.t, as it is currently broken
if `PYTHON3=/bin/python3` is set.
Reviewed By: wez, phillco, simpkins, pkaush, singhsrb
Differential Revision: D8173629
fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b
2018-05-26 07:34:37 +03:00
|
|
|
$ hg debugrebuilddirstate 2>&1 | grep 'multiple processors'
|
2017-10-17 20:31:44 +03:00
|
|
|
Abort: cannot register multiple processors on flag '0x8'.
|
2017-06-06 17:09:48 +03:00
|
|
|
*** failed to set up extension duplicate: cannot register multiple processors on flag '0x8'.
|
2017-08-01 02:32:01 +03:00
|
|
|
$ hg st 2>&1 | egrep 'cannot register multiple processors|flagprocessorext'
|
2017-10-17 20:31:44 +03:00
|
|
|
File "*/tests/flagprocessorext.py", line *, in extsetup (glob)
|
|
|
|
Abort: cannot register multiple processors on flag '0x8'.
|
2017-08-01 02:32:01 +03:00
|
|
|
*** failed to set up extension duplicate: cannot register multiple processors on flag '0x8'.
|
|
|
|
File "*/tests/flagprocessorext.py", line *, in b64decode (glob)
|
2017-04-07 03:24:36 +03:00
|
|
|
|
|
|
|
$ cd ..
|
|
|
|
|
|
|
|
# TEST: bundle repo
|
|
|
|
$ hg init bundletest
|
|
|
|
$ cd bundletest
|
|
|
|
|
|
|
|
$ cat >> .hg/hgrc << EOF
|
|
|
|
> [extensions]
|
|
|
|
> flagprocessor=$TESTDIR/flagprocessorext.py
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
$ for i in 0 single two three 4; do
|
|
|
|
> echo '[BASE64]a-bit-longer-'$i > base64
|
|
|
|
> hg commit -m base64-$i -A base64
|
|
|
|
> done
|
|
|
|
|
|
|
|
$ hg update 2 -q
|
|
|
|
$ echo '[BASE64]a-bit-longer-branching' > base64
|
|
|
|
$ hg commit -q -m branching
|
|
|
|
|
|
|
|
$ hg bundle --base 1 bundle.hg
|
|
|
|
4 changesets found
|
|
|
|
$ hg --config extensions.strip= strip -r 2 --no-backup --force -q
|
2017-04-07 05:01:51 +03:00
|
|
|
$ hg -R bundle.hg log --stat -T '{rev} {desc}\n' base64
|
2017-04-07 03:45:47 +03:00
|
|
|
5 branching
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
4 base64-4
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
3 base64-three
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
2 base64-two
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
1 base64-single
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
0 base64-0
|
|
|
|
base64 | 1 +
|
|
|
|
1 files changed, 1 insertions(+), 0 deletions(-)
|
|
|
|
|
2017-04-07 03:24:36 +03:00
|
|
|
|
2017-04-07 05:01:51 +03:00
|
|
|
$ hg bundle -R bundle.hg --base 1 bundle-again.hg -q
|
|
|
|
$ hg -R bundle-again.hg log --stat -T '{rev} {desc}\n' base64
|
2017-04-03 19:31:39 +03:00
|
|
|
5 branching
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
4 base64-4
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
3 base64-three
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
2 base64-two
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
1 base64-single
|
|
|
|
base64 | 2 +-
|
|
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
|
|
|
|
0 base64-0
|
|
|
|
base64 | 1 +
|
|
|
|
1 files changed, 1 insertions(+), 0 deletions(-)
|
|
|
|
|
2017-04-07 20:56:53 +03:00
|
|
|
$ rm bundle.hg bundle-again.hg
|
|
|
|
|
|
|
|
# TEST: hg status
|
|
|
|
|
|
|
|
$ hg status
|
|
|
|
$ hg diff
|