2020-01-31 05:40:49 +03:00
|
|
|
#require py2
|
2019-12-10 02:24:31 +03:00
|
|
|
#chg-compatible
|
|
|
|
|
2020-01-20 13:42:49 +03:00
|
|
|
$ disable treemanifest
|
2016-09-08 22:16:19 +03:00
|
|
|
|
2020-01-20 13:42:49 +03:00
|
|
|
$ enable fastannotate
|
2016-09-08 22:16:19 +03:00
|
|
|
|
|
|
|
$ HGMERGE=true; export HGMERGE
|
|
|
|
|
|
|
|
$ hg init repo
|
|
|
|
$ cd repo
|
|
|
|
|
|
|
|
a simple merge case
|
|
|
|
|
|
|
|
$ echo 1 > a
|
|
|
|
$ hg commit -qAm 'append 1'
|
|
|
|
$ echo 2 >> a
|
|
|
|
$ hg commit -m 'append 2'
|
|
|
|
$ echo 3 >> a
|
|
|
|
$ hg commit -m 'append 3'
|
|
|
|
$ hg up 1 -q
|
|
|
|
$ cat > a << EOF
|
|
|
|
> 0
|
|
|
|
> 1
|
|
|
|
> 2
|
|
|
|
> EOF
|
|
|
|
$ hg commit -qm 'insert 0'
|
|
|
|
$ hg merge 2 -q
|
|
|
|
$ echo 4 >> a
|
|
|
|
$ hg commit -m merge
|
|
|
|
$ hg log -G -T '{rev}: {desc}'
|
|
|
|
@ 4: merge
|
|
|
|
|\
|
|
|
|
| o 3: insert 0
|
|
|
|
| |
|
|
|
|
o | 2: append 3
|
|
|
|
|/
|
|
|
|
o 1: append 2
|
|
|
|
|
|
|
|
|
o 0: append 1
|
|
|
|
|
|
|
|
$ hg fastannotate a
|
|
|
|
3: 0
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
2: 3
|
|
|
|
4: 4
|
|
|
|
$ hg fastannotate -r 0 a
|
|
|
|
0: 1
|
|
|
|
$ hg fastannotate -r 1 a
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
$ hg fastannotate -udnclf a
|
|
|
|
test 3 d641cb51f61e Thu Jan 01 00:00:00 1970 +0000 a:1: 0
|
|
|
|
test 0 4994017376d3 Thu Jan 01 00:00:00 1970 +0000 a:1: 1
|
|
|
|
test 1 e940cb6d9a06 Thu Jan 01 00:00:00 1970 +0000 a:2: 2
|
|
|
|
test 2 26162a884ba6 Thu Jan 01 00:00:00 1970 +0000 a:3: 3
|
|
|
|
test 4 3ad7bcd2815f Thu Jan 01 00:00:00 1970 +0000 a:5: 4
|
|
|
|
$ hg fastannotate --linear a
|
|
|
|
3: 0
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
4: 3
|
|
|
|
4: 4
|
|
|
|
|
|
|
|
incrementally updating
|
|
|
|
|
|
|
|
$ hg fastannotate -r 0 a --debug
|
fastannotate: handle "draft" paths, and renames correctly
Summary:
Previously we can only answer the "path" information when the revision is in
the linelog revmap, and the code would crash if a revision is in a side
branch, and the user requests path information. This diff fixes it.
Besides, this diff improves rename handling. For example, given the following
chart:
```
o---o -o file name: a
/
o---o- file name: b
^ ^ ^
1 2 3 revisions
```
Depending on the position of the `main branch` reference, fastannotate may
or may not use linelog:
- main branch is at rev 2, annotate a -r 3 will not take advantage of linelog
(fallback to slow annotate)
- main branch is at rev 3, annotate a -r 2 will not take advantage of linelog
This is not ideal, but seems to be the best we can do for now.
Test Plan:
Added a new test, updated existing relevant tests. Some debug messages are
changed to reflect internals more precisely.
Reviewers: #sourcecontrol, stash
Reviewed By: stash
Subscribers: stash, mjpieters
Differential Revision: https://phabricator.intern.facebook.com/D4010964
Signature: t1:4010964:1476458201:79875d96399d023d0000d0c4bb8b8d40ea43eef0
2016-10-09 21:47:01 +03:00
|
|
|
fastannotate: a: using fast path (resolved fctx: True)
|
2016-09-08 22:16:19 +03:00
|
|
|
0: 1
|
|
|
|
$ hg fastannotate -r 0 a --debug --rebuild
|
|
|
|
fastannotate: a: 1 new changesets in the main branch
|
|
|
|
0: 1
|
|
|
|
$ hg fastannotate -r 1 a --debug
|
|
|
|
fastannotate: a: 1 new changesets in the main branch
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
$ hg fastannotate -r 3 a --debug
|
|
|
|
fastannotate: a: 1 new changesets in the main branch
|
|
|
|
3: 0
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
$ hg fastannotate -r 4 a --debug
|
|
|
|
fastannotate: a: 1 new changesets in the main branch
|
|
|
|
3: 0
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
2: 3
|
|
|
|
4: 4
|
|
|
|
$ hg fastannotate -r 1 a --debug
|
fastannotate: handle "draft" paths, and renames correctly
Summary:
Previously we can only answer the "path" information when the revision is in
the linelog revmap, and the code would crash if a revision is in a side
branch, and the user requests path information. This diff fixes it.
Besides, this diff improves rename handling. For example, given the following
chart:
```
o---o -o file name: a
/
o---o- file name: b
^ ^ ^
1 2 3 revisions
```
Depending on the position of the `main branch` reference, fastannotate may
or may not use linelog:
- main branch is at rev 2, annotate a -r 3 will not take advantage of linelog
(fallback to slow annotate)
- main branch is at rev 3, annotate a -r 2 will not take advantage of linelog
This is not ideal, but seems to be the best we can do for now.
Test Plan:
Added a new test, updated existing relevant tests. Some debug messages are
changed to reflect internals more precisely.
Reviewers: #sourcecontrol, stash
Reviewed By: stash
Subscribers: stash, mjpieters
Differential Revision: https://phabricator.intern.facebook.com/D4010964
Signature: t1:4010964:1476458201:79875d96399d023d0000d0c4bb8b8d40ea43eef0
2016-10-09 21:47:01 +03:00
|
|
|
fastannotate: a: using fast path (resolved fctx: True)
|
2016-09-08 22:16:19 +03:00
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
|
|
|
|
rebuild happens automatically if unable to update
|
|
|
|
|
|
|
|
$ hg fastannotate -r 2 a --debug
|
|
|
|
fastannotate: a: cache broken and deleted
|
|
|
|
fastannotate: a: 3 new changesets in the main branch
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
2: 3
|
|
|
|
|
|
|
|
config option "fastannotate.mainbranch"
|
|
|
|
|
|
|
|
$ hg fastannotate -r 1 --rebuild --config fastannotate.mainbranch=tip a --debug
|
|
|
|
fastannotate: a: 4 new changesets in the main branch
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
$ hg fastannotate -r 4 a --debug
|
fastannotate: handle "draft" paths, and renames correctly
Summary:
Previously we can only answer the "path" information when the revision is in
the linelog revmap, and the code would crash if a revision is in a side
branch, and the user requests path information. This diff fixes it.
Besides, this diff improves rename handling. For example, given the following
chart:
```
o---o -o file name: a
/
o---o- file name: b
^ ^ ^
1 2 3 revisions
```
Depending on the position of the `main branch` reference, fastannotate may
or may not use linelog:
- main branch is at rev 2, annotate a -r 3 will not take advantage of linelog
(fallback to slow annotate)
- main branch is at rev 3, annotate a -r 2 will not take advantage of linelog
This is not ideal, but seems to be the best we can do for now.
Test Plan:
Added a new test, updated existing relevant tests. Some debug messages are
changed to reflect internals more precisely.
Reviewers: #sourcecontrol, stash
Reviewed By: stash
Subscribers: stash, mjpieters
Differential Revision: https://phabricator.intern.facebook.com/D4010964
Signature: t1:4010964:1476458201:79875d96399d023d0000d0c4bb8b8d40ea43eef0
2016-10-09 21:47:01 +03:00
|
|
|
fastannotate: a: using fast path (resolved fctx: True)
|
2016-09-08 22:16:19 +03:00
|
|
|
3: 0
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
2: 3
|
|
|
|
4: 4
|
|
|
|
|
fastannotate: support replacing fctx.annotate directly
Summary:
Previously, I have performance concern about the signature of
`fctx.annotate`: it returns fctxs, not ideal for performance since my
initial goal is to get rid of reading revlogs in the best case. And letting
the low-level `fctx.annotate` have some side effects writing to the disk is
not that pretty.
Because of that, fastannotate had re-invent part of the formatter (also
optimized for performance somehow), and still cannot support all the
features the original annotate supports, namely, templates.
Now it makes sense to just replace `fctx.annotate` with a sub-optimal
implementation, just for the flexibility of the template support of the
original annotate command. We can use a "fake" or "lazy" fctx object to
minimal the performance impact when people only need to print changeset
nodes and line numbers - in which case we don't read revlog.
Actually, the hgweb support already did a similar thing - converting
fastannotate output to annotate output. So we can reuse some code.
The next planned steps are:
- Make the original "annotate" command aware of fastannotate protocol, do
the pre-download stuff (downloading cache files at `fctx.annotate` is
possible but inefficient because of not being batched).
- "fastannotate" command remains a separated command optimized for perf
and provides extra features like "--deleted".
Because of the plan, the "commands" option does not make much sense -
"fastannotate" command will not replace "annotate" directly thus dropped
from the config interface. A new "modes" config option is added to control
how fastannotate works.
Test Plan: Modified existing tests
Reviewers: #sourcecontrol, simonfar
Reviewed By: simonfar
Subscribers: mjpieters
Differential Revision: https://phabricator.intern.facebook.com/D4238998
Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
|
|
|
config option "fastannotate.modes"
|
2016-09-08 23:52:01 +03:00
|
|
|
|
|
|
|
$ hg annotate -r 1 --debug a
|
|
|
|
0: 1
|
|
|
|
1: 2
|
fastannotate: support replacing fctx.annotate directly
Summary:
Previously, I have performance concern about the signature of
`fctx.annotate`: it returns fctxs, not ideal for performance since my
initial goal is to get rid of reading revlogs in the best case. And letting
the low-level `fctx.annotate` have some side effects writing to the disk is
not that pretty.
Because of that, fastannotate had re-invent part of the formatter (also
optimized for performance somehow), and still cannot support all the
features the original annotate supports, namely, templates.
Now it makes sense to just replace `fctx.annotate` with a sub-optimal
implementation, just for the flexibility of the template support of the
original annotate command. We can use a "fake" or "lazy" fctx object to
minimal the performance impact when people only need to print changeset
nodes and line numbers - in which case we don't read revlog.
Actually, the hgweb support already did a similar thing - converting
fastannotate output to annotate output. So we can reuse some code.
The next planned steps are:
- Make the original "annotate" command aware of fastannotate protocol, do
the pre-download stuff (downloading cache files at `fctx.annotate` is
possible but inefficient because of not being batched).
- "fastannotate" command remains a separated command optimized for perf
and provides extra features like "--deleted".
Because of the plan, the "commands" option does not make much sense -
"fastannotate" command will not replace "annotate" directly thus dropped
from the config interface. A new "modes" config option is added to control
how fastannotate works.
Test Plan: Modified existing tests
Reviewers: #sourcecontrol, simonfar
Reviewed By: simonfar
Subscribers: mjpieters
Differential Revision: https://phabricator.intern.facebook.com/D4238998
Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
|
|
|
$ hg annotate --config fastannotate.modes=fctx -r 1 --debug a
|
2016-12-07 03:09:04 +03:00
|
|
|
fastannotate: a: using fast path (resolved fctx: False)
|
2016-09-08 23:52:01 +03:00
|
|
|
0: 1
|
|
|
|
1: 2
|
fastannotate: support replacing fctx.annotate directly
Summary:
Previously, I have performance concern about the signature of
`fctx.annotate`: it returns fctxs, not ideal for performance since my
initial goal is to get rid of reading revlogs in the best case. And letting
the low-level `fctx.annotate` have some side effects writing to the disk is
not that pretty.
Because of that, fastannotate had re-invent part of the formatter (also
optimized for performance somehow), and still cannot support all the
features the original annotate supports, namely, templates.
Now it makes sense to just replace `fctx.annotate` with a sub-optimal
implementation, just for the flexibility of the template support of the
original annotate command. We can use a "fake" or "lazy" fctx object to
minimal the performance impact when people only need to print changeset
nodes and line numbers - in which case we don't read revlog.
Actually, the hgweb support already did a similar thing - converting
fastannotate output to annotate output. So we can reuse some code.
The next planned steps are:
- Make the original "annotate" command aware of fastannotate protocol, do
the pre-download stuff (downloading cache files at `fctx.annotate` is
possible but inefficient because of not being batched).
- "fastannotate" command remains a separated command optimized for perf
and provides extra features like "--deleted".
Because of the plan, the "commands" option does not make much sense -
"fastannotate" command will not replace "annotate" directly thus dropped
from the config interface. A new "modes" config option is added to control
how fastannotate works.
Test Plan: Modified existing tests
Reviewers: #sourcecontrol, simonfar
Reviewed By: simonfar
Subscribers: mjpieters
Differential Revision: https://phabricator.intern.facebook.com/D4238998
Signature: t1:4238998:1480447679:c48e0e565663c086293265e104d9cf414d913aa7
2016-11-29 14:51:08 +03:00
|
|
|
$ hg fastannotate --config fastannotate.modes=fctx -h -q
|
2019-08-20 05:24:40 +03:00
|
|
|
unknown command 'fastannotate'
|
|
|
|
(use 'hg help' to get help)
|
2016-09-08 23:52:01 +03:00
|
|
|
[255]
|
|
|
|
|
2016-09-08 22:16:19 +03:00
|
|
|
rename
|
|
|
|
|
|
|
|
$ hg mv a b
|
|
|
|
$ cat > b << EOF
|
|
|
|
> 0
|
|
|
|
> 11
|
|
|
|
> 3
|
|
|
|
> 44
|
|
|
|
> EOF
|
|
|
|
$ hg commit -m b -q
|
|
|
|
$ hg fastannotate -ncf --long-hash b
|
|
|
|
3 d641cb51f61e331c44654104301f8154d7865c89 a: 0
|
|
|
|
5 d44dade239915bc82b91e4556b1257323f8e5824 b: 11
|
|
|
|
2 26162a884ba60e8c87bf4e0d6bb8efcc6f711a4e a: 3
|
|
|
|
5 d44dade239915bc82b91e4556b1257323f8e5824 b: 44
|
|
|
|
$ hg fastannotate -r 26162a884ba60e8c87bf4e0d6bb8efcc6f711a4e a
|
|
|
|
0: 1
|
|
|
|
1: 2
|
|
|
|
2: 3
|
2016-09-12 00:52:29 +03:00
|
|
|
|
|
|
|
fastannotate --deleted
|
|
|
|
|
|
|
|
$ hg fastannotate --deleted -nf b
|
|
|
|
3 a: 0
|
|
|
|
5 b: 11
|
|
|
|
0 a: -1
|
|
|
|
1 a: -2
|
|
|
|
2 a: 3
|
|
|
|
5 b: 44
|
|
|
|
4 a: -4
|
|
|
|
$ hg fastannotate --deleted -r 3 -nf a
|
|
|
|
3 a: 0
|
|
|
|
0 a: 1
|
|
|
|
1 a: 2
|
2016-09-29 18:33:46 +03:00
|
|
|
|
|
|
|
file and directories with ".l", ".m" suffixes
|
|
|
|
|
|
|
|
$ cd ..
|
|
|
|
$ hg init repo2
|
|
|
|
$ cd repo2
|
|
|
|
|
|
|
|
$ mkdir a.l b.m c.lock a.l.hg b.hg
|
|
|
|
$ for i in a b c d d.l d.m a.l/a b.m/a c.lock/a a.l.hg/a b.hg/a; do
|
|
|
|
> echo $i > $i
|
|
|
|
> done
|
|
|
|
$ hg add . -q
|
|
|
|
$ hg commit -m init
|
|
|
|
$ hg fastannotate a.l/a b.m/a c.lock/a a.l.hg/a b.hg/a d.l d.m a b c d
|
|
|
|
0: a
|
|
|
|
0: a.l.hg/a
|
|
|
|
0: a.l/a
|
|
|
|
0: b
|
|
|
|
0: b.hg/a
|
|
|
|
0: b.m/a
|
|
|
|
0: c
|
|
|
|
0: c.lock/a
|
|
|
|
0: d
|
|
|
|
0: d.l
|
|
|
|
0: d.m
|
fastannotate: handle empty file correctly
Summary:
`_decorate` backported from upstream does not handle empty file correctly.
It would raise an assertion error when annotating an empty file:
File "fastannotate/commands.py", line 138, in fastannotate
not showdeleted))
File "fastannotate/context.py", line 331, in annotate
return self._refineannotateresult(result, revfctx, showpath, showlines)
File "fastannotate/context.py", line 503, in _refineannotateresult
if len(lines) != len(result):
AssertionError
This patch fixes it.
Test Plan: Run the modified test.
Reviewers: #sourcecontrol, stash
Reviewed By: stash
Subscribers: mjpieters
Differential Revision: https://phabricator.intern.facebook.com/D3944132
Signature: t1:3944132:1475166894:e2610c6364806b77c8533315a1a0a08b6c158fe5
2016-09-29 18:48:40 +03:00
|
|
|
|
|
|
|
empty file
|
|
|
|
|
|
|
|
$ touch empty
|
|
|
|
$ hg commit -A empty -m empty
|
|
|
|
$ hg fastannotate empty
|
2016-10-21 21:28:30 +03:00
|
|
|
|
|
|
|
json format
|
|
|
|
|
|
|
|
$ hg fastannotate -Tjson -cludn b a empty
|
|
|
|
[
|
|
|
|
{
|
|
|
|
"date": [0.0, 0],
|
|
|
|
"line": "a\n",
|
|
|
|
"line_number": 1,
|
|
|
|
"node": "1fd620b16252aecb54c6aa530dff5ed6e6ec3d21",
|
|
|
|
"rev": 0,
|
|
|
|
"user": "test"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"date": [0.0, 0],
|
|
|
|
"line": "b\n",
|
|
|
|
"line_number": 1,
|
|
|
|
"node": "1fd620b16252aecb54c6aa530dff5ed6e6ec3d21",
|
|
|
|
"rev": 0,
|
|
|
|
"user": "test"
|
|
|
|
}
|
|
|
|
]
|
|
|
|
|
|
|
|
$ hg fastannotate -Tjson -cludn empty
|
|
|
|
[
|
|
|
|
]
|
|
|
|
$ hg fastannotate -Tjson --no-content -n a
|
|
|
|
[
|
|
|
|
{
|
|
|
|
"rev": 0
|
|
|
|
}
|
|
|
|
]
|
2016-10-21 22:50:37 +03:00
|
|
|
|
|
|
|
working copy
|
|
|
|
|
|
|
|
$ echo a >> a
|
|
|
|
$ hg fastannotate -r 'wdir()' a
|
|
|
|
abort: cannot update linelog to wdir()
|
|
|
|
(set fastannotate.mainbranch)
|
|
|
|
[255]
|
|
|
|
$ cat >> $HGRCPATH << EOF
|
|
|
|
> [fastannotate]
|
|
|
|
> mainbranch = .
|
|
|
|
> EOF
|
|
|
|
$ hg fastannotate -r 'wdir()' a
|
|
|
|
0 : a
|
|
|
|
1+: a
|
|
|
|
$ hg fastannotate -cludn -r 'wdir()' a
|
|
|
|
test 0 1fd620b16252 Thu Jan 01 00:00:00 1970 +0000:1: a
|
|
|
|
test 1 720582f5bdb6+ *:2: a (glob)
|
|
|
|
$ hg fastannotate -cludn -r 'wdir()' -Tjson a
|
|
|
|
[
|
|
|
|
{
|
|
|
|
"date": [0.0, 0],
|
|
|
|
"line": "a\n",
|
|
|
|
"line_number": 1,
|
|
|
|
"node": "1fd620b16252aecb54c6aa530dff5ed6e6ec3d21",
|
|
|
|
"rev": 0,
|
|
|
|
"user": "test"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"date": [*, 0], (glob)
|
|
|
|
"line": "a\n",
|
|
|
|
"line_number": 2,
|
|
|
|
"node": null,
|
|
|
|
"rev": null,
|
|
|
|
"user": "test"
|
|
|
|
}
|
|
|
|
]
|