facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 07:17:55 +03:00
Code Issues Projects Releases Wiki Activity
0d9e787fe4
sapling/tests/test-annotate.t

609 lines
10 KiB
Perl
Raw Normal View History

tests: unify test-annotate
2010-08-14 04:18:17 +04:00
$ HGMERGE=true; export HGMERGE
init
annotate: support diff whitespace filtering flags (issue3030) splitblock() was added to handle blocks returned by bdiff.blocks() which differ only by blank lines but are not made only of blank lines. I do not know exactly how it could happen but mdiff.blocks() threshold behaviour makes me think it can if those blocks are made of very popular lines mixed with popular blank lines. If it is proven to be wrong, the function can be dropped. The first implementation made annotate share diff configuration entries. But it looks like users will user -w/b for annotate but not for diff, on both the command line and hgweb. Since the latter cannot use command line entries, we introduce a new [annotate] section duplicating the diff whitespace options.
2011-11-18 15:04:31 +04:00
$ hg init repo
$ cd repo
tests: unify test-annotate
2010-08-14 04:18:17 +04:00
commit
$ echo 'a' > a
$ hg ci -A -m test -u nobody -d '1 0'
adding a
annotate -c
$ hg annotate -c a
8435f90966e4: a
annotate -cl
$ hg annotate -cl a
8435f90966e4:1: a
annotate -d
$ hg annotate -d a
Thu Jan 01 00:00:01 1970 +0000: a
annotate -n
$ hg annotate -n a
0: a
annotate -nl
$ hg annotate -nl a
0:1: a
annotate -u
$ hg annotate -u a
nobody: a
annotate -cdnu
$ hg annotate -cdnu a
nobody 0 8435f90966e4 Thu Jan 01 00:00:01 1970 +0000: a
annotate -cdnul
$ hg annotate -cdnul a
nobody 0 8435f90966e4 Thu Jan 01 00:00:01 1970 +0000:1: a
annotate: port to generic templater enabled by hidden -T option If the selected formatter is other than plainformatter, raw data are passed to the formatter. In this case, it isn't necessary (and not possible) to calculate column widths. Field names are substituted to be the same as "log" command. There are a few limitations: - "binary file" message is not included in formatted output. - no data structure for multiple files. all lines are packed to single list.
2014-09-17 18:21:20 +04:00
annotate (JSON)
$ hg annotate -Tjson a
[
{
"line": "a\n",
"rev": 0
}
]
$ hg annotate -Tjson -cdfnul a
[
{
"date": [1.0, 0],
"file": "a",
"line": "a\n",
"line_number": 1,
"node": "8435f90966e442695d2ded29fdade2bac5ad8065",
"rev": 0,
"user": "nobody"
}
]
tests: unify test-annotate
2010-08-14 04:18:17 +04:00
$ cat <<EOF >>a
> a
> a
> EOF
$ hg ci -ma1 -d '1 0'
$ hg cp a b
$ hg ci -mb -d '1 0'
$ cat <<EOF >> b
> b4
> b5
> b6
> EOF
$ hg ci -mb2 -d '2 0'
annotate -n b
$ hg annotate -n b
0: a
1: a
1: a
3: b4
3: b5
3: b6
annotate --no-follow b
$ hg annotate --no-follow b
2: a
2: a
2: a
3: b4
3: b5
3: b6
annotate -nl b
$ hg annotate -nl b
0:1: a
1:2: a
1:3: a
3:4: b4
3:5: b5
3:6: b6
annotate -nf b
$ hg annotate -nf b
0 a: a
1 a: a
1 a: a
3 b: b4
3 b: b5
3 b: b6
annotate -nlf b
$ hg annotate -nlf b
0 a:1: a
1 a:2: a
1 a:3: a
3 b:4: b4
3 b:5: b5
3 b:6: b6
$ hg up -C 2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat <<EOF >> b
> b4
> c
> b5
> EOF
$ hg ci -mb2.1 -d '2 0'
created new head
$ hg merge
merging b
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -mmergeb -d '3 0'
annotate after merge
$ hg annotate -nf b
0 a: a
1 a: a
1 a: a
3 b: b4
4 b: c
3 b: b5
annotate after merge with -l
$ hg annotate -nlf b
0 a:1: a
1 a:2: a
1 a:3: a
3 b:4: b4
4 b:5: c
3 b:5: b5
$ hg up -C 1
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg cp a b
$ cat <<EOF > b
> a
> z
> a
> EOF
$ hg ci -mc -d '3 0'
created new head
$ hg merge
merging b
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ cat <<EOF >> b
> b4
> c
> b5
> EOF
$ echo d >> b
$ hg ci -mmerge2 -d '4 0'
annotate after rename merge
$ hg annotate -nf b
0 a: a
6 b: z
1 a: a
3 b: b4
4 b: c
3 b: b5
7 b: d
annotate after rename merge with -l
$ hg annotate -nlf b
0 a:1: a
6 b:2: z
1 a:3: a
3 b:4: b4
4 b:5: c
3 b:5: b5
7 b:7: d
annotate: fix alignment of columns in front of line numbers (issue2807)
2011-05-18 17:41:03 +04:00
Issue2807: alignment of line numbers with -l
$ echo more >> b
$ hg ci -mmore -d '5 0'
$ echo more >> b
$ hg ci -mmore -d '6 0'
$ echo more >> b
$ hg ci -mmore -d '7 0'
$ hg annotate -nlf b
0 a: 1: a
6 b: 2: z
1 a: 3: a
3 b: 4: b4
4 b: 5: c
3 b: 5: b5
7 b: 7: d
8 b: 8: more
9 b: 9: more
10 b:10: more
tests: unify test-annotate
2010-08-14 04:18:17 +04:00
linkrev vs rev
$ hg annotate -r tip -n a
0: a
1: a
1: a
linkrev vs rev with -l
$ hg annotate -r tip -nl a
0:1: a
1:2: a
1:3: a
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue589: "undelete" sequence leads to crash
tests: unify test-annotate
2010-08-14 04:18:17 +04:00
annotate was crashing when trying to --follow something
like A -> B -> A
generate ABA rename configuration
$ echo foo > foo
$ hg add foo
$ hg ci -m addfoo
$ hg rename foo bar
$ hg ci -m renamefoo
$ hg rename bar foo
$ hg ci -m renamebar
annotate after ABA with follow
$ hg annotate --follow foo
foo: foo
annotate: catch nonexistent files using match.bad callback (issue1590)
2011-03-19 09:34:49 +03:00
missing file
$ hg ann nosuchfile
annotate: fix alignment of columns in front of line numbers (issue2807)
2011-05-18 17:41:03 +04:00
abort: nosuchfile: no such file in rev e9e6b4fa872f
annotate: catch nonexistent files using match.bad callback (issue1590)
2011-03-19 09:34:49 +03:00
[255]
annotate: support diff whitespace filtering flags (issue3030) splitblock() was added to handle blocks returned by bdiff.blocks() which differ only by blank lines but are not made only of blank lines. I do not know exactly how it could happen but mdiff.blocks() threshold behaviour makes me think it can if those blocks are made of very popular lines mixed with popular blank lines. If it is proven to be wrong, the function can be dropped. The first implementation made annotate share diff configuration entries. But it looks like users will user -w/b for annotate but not for diff, on both the command line and hgweb. Since the latter cannot use command line entries, we introduce a new [annotate] section duplicating the diff whitespace options.
2011-11-18 15:04:31 +04:00
annotate: append newline after non newline-terminated file listings The last line of a non newline-terminated file would mix with the first line of the next file in multiple-file listings before this patch. Possible compatibility issue: no longer possible to tell from the annotate output if the file is terminated by new line or not.
2012-01-10 12:18:19 +04:00
annotate file without '\n' on last line
$ printf "" > c
$ hg ci -A -m test -u nobody -d '1 0'
adding c
$ hg annotate c
$ printf "a\nb" > c
$ hg ci -m test
$ hg annotate c
[0-9]+: a (re)
[0-9]+: b (re)
annotate: increase refcount of each revisions correctly (issue3841) Before this patch, refcount (managed in "needed") of parents of each revisions in "visit" is increased, only when parent is not annotated yet (examined by "p not in hist"). But this causes less refcount of the revision like "A" in the tree below ("A" is assumed as the second parent of "C"): A --- B --- C \ / \-----/ Steps of annotation for "C" in this case are shown below: 1. for "C" 1.1 increase refcount of "B" 1.2 increase refcount of "A" (=> 1) 1.3 defer annotation for "C" 2. for "A" 2.1 annotate for "A" (=> put result into "hist[A]") 2.2 clear "pcache[A]" ("pcache[A] = []") 3. for "B" 3.1 not increase refcount of "A", because "A not in hist" is False 3.2 annotate for "B" 3.3 decrease refcount of "A" (=> 0) 3.4 delete "hist[A]", even though "A" is still needed by "C" 3.5 clear "pcache[B]" 4. for "C", again 4.1 not increase refcount of "B", because "B not in hist" is False 4.2 increase refcount of "A" (=> 1) 4.3 defer annotation for "C" 5. for "A", again 5.1 annotate for "A" (=> put result into "hist[A]", again) 5.2 clear "pcache[A]" 6. for "C", once again 6.1 not increase refcount of "B", because "B not in hist" is False 6.2 not increase refcount of "A", because "A not in hist" is False 6.3 annotate for "C" 6.4 decrease refcount of "A", and delete "hist[A]" 6.5 decrease refcount of "B", and delete "hist[B]" 6.6 clear "pcache[C]" At step (5.1), annotation for "A" mis-recognizes that all lines are created at "A", because "pcache[A]" already cleared at step (2.2) prevents from scanning ancestors of "A". So, annotation for "C" or its descendants loses information about "A" or its ancestors. The root cause of this problem is that refcount of "A" is decreased at step (3.3), even though it isn't increased at step (3.1). To increase refcount correctly, this patch increases refcount of each parents of each revisions: - regardless of "p not in hist" or not, and - only once for each revisions in "visit" (by "not pcached") In fact, this problem should occur only on legacy repositories in which a filelog includes the merging between the revision and its ancestor (as the second parent), because: - tree is scanned in depth-first without such merging, revisions in "visit" refer different revisions as parent each other - recent Mercurial doesn't allow such merging changelog and manifest can include such merging someway, but filelogs can't, because "localrepository._filecommit()" converts such merging request to linear history. This patch tests merging cases below: these cases are from filelog of "mercurial/commands.py" in the repository of Mercurial itself. - both parents are same 10 --- 11 --- 12 \_/ filelogrev: changesetid: 10 526aca6bcb38 11 05098100ff44 12 2d4f4cfa81d6 - the second parent is also ancestor of the first one 37 --- 38 --- 39 --- 40 \________/ filelogrev: changesetid: 37 033dc4170fe6 38 5ff1a23ce38c 39 661a47367859 40 a2ba99fd026f
2013-03-29 17:57:16 +04:00
Issue3841: check annotation of the file of which filelog includes
merging between the revision and its ancestor
to reproduce the situation with recent Mercurial, this script uses (1)
"hg debugsetparents" to merge without ancestor check by "hg merge",
and (2) the extension to allow filelog merging between the revision
and its ancestor by overriding "repo._filecommit".
$ cat > ../legacyrepo.py <<EOF
error: get Abort from 'error' instead of 'util' The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be confused about that and gives all the credit to 'util' instead of the hardworking 'error'. In a spirit of equity, we break the cycle of injustice and give back to 'error' the respect it deserves. And screw that 'util' poser. For great justice.
2015-10-08 22:55:45 +03:00
> from mercurial import node, error
annotate: increase refcount of each revisions correctly (issue3841) Before this patch, refcount (managed in "needed") of parents of each revisions in "visit" is increased, only when parent is not annotated yet (examined by "p not in hist"). But this causes less refcount of the revision like "A" in the tree below ("A" is assumed as the second parent of "C"): A --- B --- C \ / \-----/ Steps of annotation for "C" in this case are shown below: 1. for "C" 1.1 increase refcount of "B" 1.2 increase refcount of "A" (=> 1) 1.3 defer annotation for "C" 2. for "A" 2.1 annotate for "A" (=> put result into "hist[A]") 2.2 clear "pcache[A]" ("pcache[A] = []") 3. for "B" 3.1 not increase refcount of "A", because "A not in hist" is False 3.2 annotate for "B" 3.3 decrease refcount of "A" (=> 0) 3.4 delete "hist[A]", even though "A" is still needed by "C" 3.5 clear "pcache[B]" 4. for "C", again 4.1 not increase refcount of "B", because "B not in hist" is False 4.2 increase refcount of "A" (=> 1) 4.3 defer annotation for "C" 5. for "A", again 5.1 annotate for "A" (=> put result into "hist[A]", again) 5.2 clear "pcache[A]" 6. for "C", once again 6.1 not increase refcount of "B", because "B not in hist" is False 6.2 not increase refcount of "A", because "A not in hist" is False 6.3 annotate for "C" 6.4 decrease refcount of "A", and delete "hist[A]" 6.5 decrease refcount of "B", and delete "hist[B]" 6.6 clear "pcache[C]" At step (5.1), annotation for "A" mis-recognizes that all lines are created at "A", because "pcache[A]" already cleared at step (2.2) prevents from scanning ancestors of "A". So, annotation for "C" or its descendants loses information about "A" or its ancestors. The root cause of this problem is that refcount of "A" is decreased at step (3.3), even though it isn't increased at step (3.1). To increase refcount correctly, this patch increases refcount of each parents of each revisions: - regardless of "p not in hist" or not, and - only once for each revisions in "visit" (by "not pcached") In fact, this problem should occur only on legacy repositories in which a filelog includes the merging between the revision and its ancestor (as the second parent), because: - tree is scanned in depth-first without such merging, revisions in "visit" refer different revisions as parent each other - recent Mercurial doesn't allow such merging changelog and manifest can include such merging someway, but filelogs can't, because "localrepository._filecommit()" converts such merging request to linear history. This patch tests merging cases below: these cases are from filelog of "mercurial/commands.py" in the repository of Mercurial itself. - both parents are same 10 --- 11 --- 12 \_/ filelogrev: changesetid: 10 526aca6bcb38 11 05098100ff44 12 2d4f4cfa81d6 - the second parent is also ancestor of the first one 37 --- 38 --- 39 --- 40 \________/ filelogrev: changesetid: 37 033dc4170fe6 38 5ff1a23ce38c 39 661a47367859 40 a2ba99fd026f
2013-03-29 17:57:16 +04:00
> def reposetup(ui, repo):
> class legacyrepo(repo.__class__):
> def _filecommit(self, fctx, manifest1, manifest2,
> linkrev, tr, changelist):
> fname = fctx.path()
> text = fctx.data()
> flog = self.file(fname)
> fparent1 = manifest1.get(fname, node.nullid)
> fparent2 = manifest2.get(fname, node.nullid)
> meta = {}
> copy = fctx.renamed()
> if copy and copy[0] != fname:
error: get Abort from 'error' instead of 'util' The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be confused about that and gives all the credit to 'util' instead of the hardworking 'error'. In a spirit of equity, we break the cycle of injustice and give back to 'error' the respect it deserves. And screw that 'util' poser. For great justice.
2015-10-08 22:55:45 +03:00
> raise error.Abort('copying is not supported')
annotate: increase refcount of each revisions correctly (issue3841) Before this patch, refcount (managed in "needed") of parents of each revisions in "visit" is increased, only when parent is not annotated yet (examined by "p not in hist"). But this causes less refcount of the revision like "A" in the tree below ("A" is assumed as the second parent of "C"): A --- B --- C \ / \-----/ Steps of annotation for "C" in this case are shown below: 1. for "C" 1.1 increase refcount of "B" 1.2 increase refcount of "A" (=> 1) 1.3 defer annotation for "C" 2. for "A" 2.1 annotate for "A" (=> put result into "hist[A]") 2.2 clear "pcache[A]" ("pcache[A] = []") 3. for "B" 3.1 not increase refcount of "A", because "A not in hist" is False 3.2 annotate for "B" 3.3 decrease refcount of "A" (=> 0) 3.4 delete "hist[A]", even though "A" is still needed by "C" 3.5 clear "pcache[B]" 4. for "C", again 4.1 not increase refcount of "B", because "B not in hist" is False 4.2 increase refcount of "A" (=> 1) 4.3 defer annotation for "C" 5. for "A", again 5.1 annotate for "A" (=> put result into "hist[A]", again) 5.2 clear "pcache[A]" 6. for "C", once again 6.1 not increase refcount of "B", because "B not in hist" is False 6.2 not increase refcount of "A", because "A not in hist" is False 6.3 annotate for "C" 6.4 decrease refcount of "A", and delete "hist[A]" 6.5 decrease refcount of "B", and delete "hist[B]" 6.6 clear "pcache[C]" At step (5.1), annotation for "A" mis-recognizes that all lines are created at "A", because "pcache[A]" already cleared at step (2.2) prevents from scanning ancestors of "A". So, annotation for "C" or its descendants loses information about "A" or its ancestors. The root cause of this problem is that refcount of "A" is decreased at step (3.3), even though it isn't increased at step (3.1). To increase refcount correctly, this patch increases refcount of each parents of each revisions: - regardless of "p not in hist" or not, and - only once for each revisions in "visit" (by "not pcached") In fact, this problem should occur only on legacy repositories in which a filelog includes the merging between the revision and its ancestor (as the second parent), because: - tree is scanned in depth-first without such merging, revisions in "visit" refer different revisions as parent each other - recent Mercurial doesn't allow such merging changelog and manifest can include such merging someway, but filelogs can't, because "localrepository._filecommit()" converts such merging request to linear history. This patch tests merging cases below: these cases are from filelog of "mercurial/commands.py" in the repository of Mercurial itself. - both parents are same 10 --- 11 --- 12 \_/ filelogrev: changesetid: 10 526aca6bcb38 11 05098100ff44 12 2d4f4cfa81d6 - the second parent is also ancestor of the first one 37 --- 38 --- 39 --- 40 \________/ filelogrev: changesetid: 37 033dc4170fe6 38 5ff1a23ce38c 39 661a47367859 40 a2ba99fd026f
2013-03-29 17:57:16 +04:00
> if fparent2 != node.nullid:
> changelist.append(fname)
> return flog.add(text, meta, tr, linkrev,
> fparent1, fparent2)
error: get Abort from 'error' instead of 'util' The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be confused about that and gives all the credit to 'util' instead of the hardworking 'error'. In a spirit of equity, we break the cycle of injustice and give back to 'error' the respect it deserves. And screw that 'util' poser. For great justice.
2015-10-08 22:55:45 +03:00
> raise error.Abort('only merging is supported')
annotate: increase refcount of each revisions correctly (issue3841) Before this patch, refcount (managed in "needed") of parents of each revisions in "visit" is increased, only when parent is not annotated yet (examined by "p not in hist"). But this causes less refcount of the revision like "A" in the tree below ("A" is assumed as the second parent of "C"): A --- B --- C \ / \-----/ Steps of annotation for "C" in this case are shown below: 1. for "C" 1.1 increase refcount of "B" 1.2 increase refcount of "A" (=> 1) 1.3 defer annotation for "C" 2. for "A" 2.1 annotate for "A" (=> put result into "hist[A]") 2.2 clear "pcache[A]" ("pcache[A] = []") 3. for "B" 3.1 not increase refcount of "A", because "A not in hist" is False 3.2 annotate for "B" 3.3 decrease refcount of "A" (=> 0) 3.4 delete "hist[A]", even though "A" is still needed by "C" 3.5 clear "pcache[B]" 4. for "C", again 4.1 not increase refcount of "B", because "B not in hist" is False 4.2 increase refcount of "A" (=> 1) 4.3 defer annotation for "C" 5. for "A", again 5.1 annotate for "A" (=> put result into "hist[A]", again) 5.2 clear "pcache[A]" 6. for "C", once again 6.1 not increase refcount of "B", because "B not in hist" is False 6.2 not increase refcount of "A", because "A not in hist" is False 6.3 annotate for "C" 6.4 decrease refcount of "A", and delete "hist[A]" 6.5 decrease refcount of "B", and delete "hist[B]" 6.6 clear "pcache[C]" At step (5.1), annotation for "A" mis-recognizes that all lines are created at "A", because "pcache[A]" already cleared at step (2.2) prevents from scanning ancestors of "A". So, annotation for "C" or its descendants loses information about "A" or its ancestors. The root cause of this problem is that refcount of "A" is decreased at step (3.3), even though it isn't increased at step (3.1). To increase refcount correctly, this patch increases refcount of each parents of each revisions: - regardless of "p not in hist" or not, and - only once for each revisions in "visit" (by "not pcached") In fact, this problem should occur only on legacy repositories in which a filelog includes the merging between the revision and its ancestor (as the second parent), because: - tree is scanned in depth-first without such merging, revisions in "visit" refer different revisions as parent each other - recent Mercurial doesn't allow such merging changelog and manifest can include such merging someway, but filelogs can't, because "localrepository._filecommit()" converts such merging request to linear history. This patch tests merging cases below: these cases are from filelog of "mercurial/commands.py" in the repository of Mercurial itself. - both parents are same 10 --- 11 --- 12 \_/ filelogrev: changesetid: 10 526aca6bcb38 11 05098100ff44 12 2d4f4cfa81d6 - the second parent is also ancestor of the first one 37 --- 38 --- 39 --- 40 \________/ filelogrev: changesetid: 37 033dc4170fe6 38 5ff1a23ce38c 39 661a47367859 40 a2ba99fd026f
2013-03-29 17:57:16 +04:00
> repo.__class__ = legacyrepo
> EOF
$ cat > baz <<EOF
> 1
> 2
> 3
> 4
> 5
> EOF
$ hg add baz
$ hg commit -m "baz:0"
$ cat > baz <<EOF
> 1 baz:1
> 2
> 3
> 4
> 5
> EOF
$ hg commit -m "baz:1"
$ cat > baz <<EOF
> 1 baz:1
> 2 baz:2
> 3
> 4
> 5
> EOF
$ hg debugsetparents 17 17
$ hg --config extensions.legacyrepo=../legacyrepo.py commit -m "baz:2"
$ hg debugindexdot .hg/store/data/baz.i
digraph G {
-1 -> 0
0 -> 1
1 -> 2
1 -> 2
}
$ hg annotate baz
17: 1 baz:1
18: 2 baz:2
16: 3
16: 4
16: 5
$ cat > baz <<EOF
> 1 baz:1
> 2 baz:2
> 3 baz:3
> 4
> 5
> EOF
$ hg commit -m "baz:3"
$ cat > baz <<EOF
> 1 baz:1
> 2 baz:2
> 3 baz:3
> 4 baz:4
> 5
> EOF
$ hg debugsetparents 19 18
$ hg --config extensions.legacyrepo=../legacyrepo.py commit -m "baz:4"
$ hg debugindexdot .hg/store/data/baz.i
digraph G {
-1 -> 0
0 -> 1
1 -> 2
1 -> 2
2 -> 3
3 -> 4
2 -> 4
}
$ hg annotate baz
17: 1 baz:1
18: 2 baz:2
19: 3 baz:3
20: 4 baz:4
16: 5
annotate: add option to annotate working-directory files Working revision or node is displayed with "+" suffix in plain output, but null/None in machine-readable format.
2014-08-16 12:50:55 +04:00
annotate clean file
$ hg annotate -ncr "wdir()" foo
11 472b18db256d : foo
annotate modified file
$ echo foofoo >> foo
$ hg annotate -r "wdir()" foo
11 : foo
20+: foofoo
$ hg annotate -cr "wdir()" foo
472b18db256d : foo
b6bedd5477e7+: foofoo
$ hg annotate -ncr "wdir()" foo
11 472b18db256d : foo
20 b6bedd5477e7+: foofoo
$ hg annotate --debug -ncr "wdir()" foo
11 472b18db256d1e8282064eab4bfdaf48cbfe83cd : foo
20 b6bedd5477e797f25e568a6402d4697f3f895a72+: foofoo
$ hg annotate -udr "wdir()" foo
test Thu Jan 01 00:00:00 1970 +0000: foo
test [A-Za-z0-9:+ ]+: foofoo (re)
$ hg annotate -ncr "wdir()" -Tjson foo
[
{
"line": "foo\n",
"node": "472b18db256d1e8282064eab4bfdaf48cbfe83cd",
"rev": 11
},
{
"line": "foofoo\n",
"node": null,
"rev": null
}
]
annotate added file
$ echo bar > bar
$ hg add bar
$ hg annotate -ncr "wdir()" bar
20 b6bedd5477e7+: bar
annotate renamed file
$ hg rename foo renamefoo2
$ hg annotate -ncr "wdir()" renamefoo2
11 472b18db256d : foo
20 b6bedd5477e7+: foofoo
annotate missing file
$ rm baz
test-annotate: conditionalize error output for Windows It seems better to leave the actual output in place instead of globbing everything but 'abort:', in case it starts aborting for other reasons. It isn't clear the purpose for reversing the file name position, but that originates in windows.posixfile.
2015-03-29 07:20:56 +03:00
#if windows
$ hg annotate -ncr "wdir()" baz
abort: $TESTTMP\repo\baz: The system cannot find the file specified
[255]
#else
annotate: add option to annotate working-directory files Working revision or node is displayed with "+" suffix in plain output, but null/None in machine-readable format.
2014-08-16 12:50:55 +04:00
$ hg annotate -ncr "wdir()" baz
abort: No such file or directory: $TESTTMP/repo/baz
[255]
test-annotate: conditionalize error output for Windows It seems better to leave the actual output in place instead of globbing everything but 'abort:', in case it starts aborting for other reasons. It isn't clear the purpose for reversing the file name position, but that originates in windows.posixfile.
2015-03-29 07:20:56 +03:00
#endif
annotate: add option to annotate working-directory files Working revision or node is displayed with "+" suffix in plain output, but null/None in machine-readable format.
2014-08-16 12:50:55 +04:00
annotate removed file
$ hg rm baz
test-annotate: conditionalize error output for Windows It seems better to leave the actual output in place instead of globbing everything but 'abort:', in case it starts aborting for other reasons. It isn't clear the purpose for reversing the file name position, but that originates in windows.posixfile.
2015-03-29 07:20:56 +03:00
#if windows
$ hg annotate -ncr "wdir()" baz
abort: $TESTTMP\repo\baz: The system cannot find the file specified
[255]
#else
annotate: add option to annotate working-directory files Working revision or node is displayed with "+" suffix in plain output, but null/None in machine-readable format.
2014-08-16 12:50:55 +04:00
$ hg annotate -ncr "wdir()" baz
abort: No such file or directory: $TESTTMP/repo/baz
[255]
test-annotate: conditionalize error output for Windows It seems better to leave the actual output in place instead of globbing everything but 'abort:', in case it starts aborting for other reasons. It isn't clear the purpose for reversing the file name position, but that originates in windows.posixfile.
2015-03-29 07:20:56 +03:00
#endif
annotate: add option to annotate working-directory files Working revision or node is displayed with "+" suffix in plain output, but null/None in machine-readable format.
2014-08-16 12:50:55 +04:00
annotate: support diff whitespace filtering flags (issue3030) splitblock() was added to handle blocks returned by bdiff.blocks() which differ only by blank lines but are not made only of blank lines. I do not know exactly how it could happen but mdiff.blocks() threshold behaviour makes me think it can if those blocks are made of very popular lines mixed with popular blank lines. If it is proven to be wrong, the function can be dropped. The first implementation made annotate share diff configuration entries. But it looks like users will user -w/b for annotate but not for diff, on both the command line and hgweb. Since the latter cannot use command line entries, we introduce a new [annotate] section duplicating the diff whitespace options.
2011-11-18 15:04:31 +04:00
Test annotate with whitespace options
$ cd ..
$ hg init repo-ws
$ cd repo-ws
$ cat > a <<EOF
> aa
>
> b b
> EOF
$ hg ci -Am "adda"
adding a
check-code: fix check for trailing whitespace on continued lines too The tests in test-annotate.t and test-import-git.t that relied on trailing space in a file created by a here string is now masked by a literal 'EOL' string that is removed.
2012-08-08 20:10:37 +04:00
$ sed 's/EOL$//g' > a <<EOF
annotate: support diff whitespace filtering flags (issue3030) splitblock() was added to handle blocks returned by bdiff.blocks() which differ only by blank lines but are not made only of blank lines. I do not know exactly how it could happen but mdiff.blocks() threshold behaviour makes me think it can if those blocks are made of very popular lines mixed with popular blank lines. If it is proven to be wrong, the function can be dropped. The first implementation made annotate share diff configuration entries. But it looks like users will user -w/b for annotate but not for diff, on both the command line and hgweb. Since the latter cannot use command line entries, we introduce a new [annotate] section duplicating the diff whitespace options.
2011-11-18 15:04:31 +04:00
> a a
>
check-code: fix check for trailing whitespace on continued lines too The tests in test-annotate.t and test-import-git.t that relied on trailing space in a file created by a here string is now masked by a literal 'EOL' string that is removed.
2012-08-08 20:10:37 +04:00
> EOL
annotate: support diff whitespace filtering flags (issue3030) splitblock() was added to handle blocks returned by bdiff.blocks() which differ only by blank lines but are not made only of blank lines. I do not know exactly how it could happen but mdiff.blocks() threshold behaviour makes me think it can if those blocks are made of very popular lines mixed with popular blank lines. If it is proven to be wrong, the function can be dropped. The first implementation made annotate share diff configuration entries. But it looks like users will user -w/b for annotate but not for diff, on both the command line and hgweb. Since the latter cannot use command line entries, we introduce a new [annotate] section duplicating the diff whitespace options.
2011-11-18 15:04:31 +04:00
> b b
> EOF
$ hg ci -m "changea"
Annotate with no option
$ hg annotate a
1: a a
0:
1:
1: b b
Annotate with --ignore-space-change
$ hg annotate --ignore-space-change a
1: a a
1:
0:
0: b b
Annotate with --ignore-all-space
$ hg annotate --ignore-all-space a
0: a a
0:
1:
0: b b
Annotate with --ignore-blank-lines (similar to no options case)
$ hg annotate --ignore-blank-lines a
1: a a
0:
1:
1: b b
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
$ cd ..
filectx.parents: enforce changeid of parent to be in own changectx ancestors Because of the way filenodes are computed, you can have multiple changesets "introducing" the same file revision. For example, in the changeset graph below, changeset 2 and 3 both change a file -to- and -from- the same content. o 3: content = new | | o 2: content = new |/ o 1: content = old In such cases, the file revision is create once, when 2 is added, and just reused for 3. So the file change in '3' (from "old" to "new)" has no linkrev pointing to it). We'll call this situation "linkrev-shadowing". As the linkrev is used for optimization purposes when walking a file history, the linkrev-shadowing results in an unexpected jump to another branch during such a walk.. This leads to multiple bugs with log, annotate and rename detection. One element to fix such bugs is to ensure that walking the file history sticks on the same topology as the changeset's history. For this purpose, we extend the logic in 'basefilectx.parents' so that it always defines the proper changeset to associate the parent file revision with. This "proper" changeset has to be an ancestor of the changeset associated with the child file revision. This logic is performed in the '_adjustlinkrev' function. This function is given the starting changeset and all the information regarding the parent file revision. If the linkrev for the file revision is an ancestor of the starting changeset, the linkrev is valid and will be used. If it is not, we detected a topological jump caused by linkrev shadowing, we are going to walk the ancestors of the starting changeset until we find one setting the file to the revision we are trying to create. The performance impact appears acceptable: - We are walking the changelog once for each filelog traversal (as there should be no overlap between searches), - changelog traversal itself is fairly cheap, compared to what is likely going to be perform on the result on the filelog traversal, - We only touch the manifest for ancestors touching the file, And such changesets are likely to be the one introducing the file. (except in pathological cases involving merge), - We use manifest diff instead of full manifest unpacking to check manifest content, so it does not involve applying multiple diffs in most case. - linkrev shadowing is not the common case. Tests for fixed issues in log, annotate and rename detection have been added. But this changeset does not solve all problems. It fixes -ancestry- computation, but if the linkrev-shadowed changesets is the starting one, we'll still get things wrong. We'll have to fix the bootstrapping of such operations in a later changeset. Also, the usage of `hg log FILE` without --follow still has issues with linkrev pointing to hidden changesets, because it relies on the `filelog` revset which implement its own traversal logic that is still to be fixed. Thanks goes to: - Matt Mackall: for nudging me in the right direction - Julien Cristau and Rémi Cardona: for keep telling me linkrev bug were an evolution show stopper for 3 years. - Durham Goode: for finding a new linkrev issue every few weeks - Mads Kiilerich: for that last rename bug who raise this topic over my anoyance limit.
2014-12-24 02:30:38 +03:00
Annotate with linkrev pointing to another branch
------------------------------------------------
create history with a filerev whose linkrev points to another branch
$ hg init branchedlinkrev
$ cd branchedlinkrev
$ echo A > a
$ hg commit -Am 'contentA'
adding a
$ echo B >> a
$ hg commit -m 'contentB'
$ hg up --rev 'desc(contentA)'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo unrelated > unrelated
$ hg commit -Am 'unrelated'
adding unrelated
created new head
$ hg graft -r 'desc(contentB)'
grafting 1:fd27c222e3e6 "contentB"
$ echo C >> a
$ hg commit -m 'contentC'
committablefilectx: propagate ancestry info to parent to fix annotation Before this patch, annotating working directory could include wrong revisions that were hidden or belonged to different branches. This fixes wfctx.parents() to set _descendantrev so that all ancestors can take advantage of the linkrev adjustment introduced at a5aaaeedd6cb. _adjustlinkrev() can handle 'None' revision thanks to bb19d597bbcd.
2015-04-18 08:10:55 +03:00
$ echo W >> a
filectx.parents: enforce changeid of parent to be in own changectx ancestors Because of the way filenodes are computed, you can have multiple changesets "introducing" the same file revision. For example, in the changeset graph below, changeset 2 and 3 both change a file -to- and -from- the same content. o 3: content = new | | o 2: content = new |/ o 1: content = old In such cases, the file revision is create once, when 2 is added, and just reused for 3. So the file change in '3' (from "old" to "new)" has no linkrev pointing to it). We'll call this situation "linkrev-shadowing". As the linkrev is used for optimization purposes when walking a file history, the linkrev-shadowing results in an unexpected jump to another branch during such a walk.. This leads to multiple bugs with log, annotate and rename detection. One element to fix such bugs is to ensure that walking the file history sticks on the same topology as the changeset's history. For this purpose, we extend the logic in 'basefilectx.parents' so that it always defines the proper changeset to associate the parent file revision with. This "proper" changeset has to be an ancestor of the changeset associated with the child file revision. This logic is performed in the '_adjustlinkrev' function. This function is given the starting changeset and all the information regarding the parent file revision. If the linkrev for the file revision is an ancestor of the starting changeset, the linkrev is valid and will be used. If it is not, we detected a topological jump caused by linkrev shadowing, we are going to walk the ancestors of the starting changeset until we find one setting the file to the revision we are trying to create. The performance impact appears acceptable: - We are walking the changelog once for each filelog traversal (as there should be no overlap between searches), - changelog traversal itself is fairly cheap, compared to what is likely going to be perform on the result on the filelog traversal, - We only touch the manifest for ancestors touching the file, And such changesets are likely to be the one introducing the file. (except in pathological cases involving merge), - We use manifest diff instead of full manifest unpacking to check manifest content, so it does not involve applying multiple diffs in most case. - linkrev shadowing is not the common case. Tests for fixed issues in log, annotate and rename detection have been added. But this changeset does not solve all problems. It fixes -ancestry- computation, but if the linkrev-shadowed changesets is the starting one, we'll still get things wrong. We'll have to fix the bootstrapping of such operations in a later changeset. Also, the usage of `hg log FILE` without --follow still has issues with linkrev pointing to hidden changesets, because it relies on the `filelog` revset which implement its own traversal logic that is still to be fixed. Thanks goes to: - Matt Mackall: for nudging me in the right direction - Julien Cristau and Rémi Cardona: for keep telling me linkrev bug were an evolution show stopper for 3 years. - Durham Goode: for finding a new linkrev issue every few weeks - Mads Kiilerich: for that last rename bug who raise this topic over my anoyance limit.
2014-12-24 02:30:38 +03:00
$ hg log -G
@ changeset: 4:072f1e8df249
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: contentC
|
o changeset: 3:ff38df03cc4b
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: contentB
|
o changeset: 2:62aaf3f6fc06
| parent: 0:f0932f74827e
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: unrelated
|
| o changeset: 1:fd27c222e3e6
|/ user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: contentB
|
o changeset: 0:f0932f74827e
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: contentA
Annotate should list ancestor of starting revision only
$ hg annotate a
0: A
3: B
4: C
committablefilectx: propagate ancestry info to parent to fix annotation Before this patch, annotating working directory could include wrong revisions that were hidden or belonged to different branches. This fixes wfctx.parents() to set _descendantrev so that all ancestors can take advantage of the linkrev adjustment introduced at a5aaaeedd6cb. _adjustlinkrev() can handle 'None' revision thanks to bb19d597bbcd.
2015-04-18 08:10:55 +03:00
$ hg annotate a -r 'wdir()'
0 : A
3 : B
4 : C
4+: W
linkrev: also adjust linkrev when bootstrapping annotate (issue4305) The annotate logic now use the new 'introrev' method to bootstrap its traversal. This catches issues from linkrev-shadowing of the changeset introducing the version of a file in source changeset. More tests have been added to display pathological cases.
2014-12-24 14:26:48 +03:00
Even when the starting revision is the linkrev-shadowed one:
$ hg annotate a -r 3
0: A
3: B
filectx.parents: enforce changeid of parent to be in own changectx ancestors Because of the way filenodes are computed, you can have multiple changesets "introducing" the same file revision. For example, in the changeset graph below, changeset 2 and 3 both change a file -to- and -from- the same content. o 3: content = new | | o 2: content = new |/ o 1: content = old In such cases, the file revision is create once, when 2 is added, and just reused for 3. So the file change in '3' (from "old" to "new)" has no linkrev pointing to it). We'll call this situation "linkrev-shadowing". As the linkrev is used for optimization purposes when walking a file history, the linkrev-shadowing results in an unexpected jump to another branch during such a walk.. This leads to multiple bugs with log, annotate and rename detection. One element to fix such bugs is to ensure that walking the file history sticks on the same topology as the changeset's history. For this purpose, we extend the logic in 'basefilectx.parents' so that it always defines the proper changeset to associate the parent file revision with. This "proper" changeset has to be an ancestor of the changeset associated with the child file revision. This logic is performed in the '_adjustlinkrev' function. This function is given the starting changeset and all the information regarding the parent file revision. If the linkrev for the file revision is an ancestor of the starting changeset, the linkrev is valid and will be used. If it is not, we detected a topological jump caused by linkrev shadowing, we are going to walk the ancestors of the starting changeset until we find one setting the file to the revision we are trying to create. The performance impact appears acceptable: - We are walking the changelog once for each filelog traversal (as there should be no overlap between searches), - changelog traversal itself is fairly cheap, compared to what is likely going to be perform on the result on the filelog traversal, - We only touch the manifest for ancestors touching the file, And such changesets are likely to be the one introducing the file. (except in pathological cases involving merge), - We use manifest diff instead of full manifest unpacking to check manifest content, so it does not involve applying multiple diffs in most case. - linkrev shadowing is not the common case. Tests for fixed issues in log, annotate and rename detection have been added. But this changeset does not solve all problems. It fixes -ancestry- computation, but if the linkrev-shadowed changesets is the starting one, we'll still get things wrong. We'll have to fix the bootstrapping of such operations in a later changeset. Also, the usage of `hg log FILE` without --follow still has issues with linkrev pointing to hidden changesets, because it relies on the `filelog` revset which implement its own traversal logic that is still to be fixed. Thanks goes to: - Matt Mackall: for nudging me in the right direction - Julien Cristau and Rémi Cardona: for keep telling me linkrev bug were an evolution show stopper for 3 years. - Durham Goode: for finding a new linkrev issue every few weeks - Mads Kiilerich: for that last rename bug who raise this topic over my anoyance limit.
2014-12-24 02:30:38 +03:00
$ cd ..
Reference in New Issue Copy Permalink