cvsps: use a different tiebreaker to avoid flaky test
After adding some sneaky debug printing[0], I determined that this
test flaked when a CVS commit containing two files starts too close to
the end of a second, thus putting file "a" in one second and "b/c" in
the following second. The secondary sort key meant that these changes
sorted in a different order when the timestamps were different than
they did when they matched. As far as I can tell, CVS walks through
the files in a stable order, so by sorting on the filenames in cvsps
we'll get stable output. It's fine for us to switch from sorting on
the branchpoint as a secondary key because this was already the point
when we didn't care, and we're just trying to break ties in a stable
way. It's unclear to be if having the branchpoint present matters
anymore, but it doesn't really hurt to leave it.
With this change in place, I was able to run test-convert-cvs over 650
times in a row without a failure. test-convert-cvcs-synthetic.t
appears to still be flaky, but I don't think it's *worse* than it was
before - just not better (I observed one flaky failure in 200 runs on
that test).
0: The helpful debug hack ended up being this, in case it's useful to
future flaky test assassins:
--- a/hgext/convert/cvsps.py
+++ b/hgext/convert/cvsps.py
@@ -854,6 +854,8 @@ def debugcvsps(ui, *args, **opts):
ui.write(('Branch: %s\n' % (cs.branch or 'HEAD')))
ui.write(('Tag%s: %s \n' % (['', 's'][len(cs.tags) > 1],
','.join(cs.tags) or '(none)')))
+ if cs.comment == 'ci1' and (cs.id == 6) == bool(cs.branchpoints):
+ ui.write('raw timestamp %r\n' % (cs.date,))
if cs.branchpoints:
ui.write(('Branchpoints: %s \n') %
', '.join(sorted(cs.branchpoints)))
$ cat >> $HGRCPATH << EOF
> [extensions]
> rebase=
>
> [experimental]
> evolution = createmarkers
> EOF
Create a repo with some tags
$ hg init repo
$ cd repo
$ echo initial > foo
$ hg -q commit -A -m initial
$ hg tag -m 'test tag' test1
$ echo first > first
$ hg -q commit -A -m first
$ hg tag -m 'test2 tag' test2
$ hg -q up -r 0
$ echo newhead > newhead
$ hg commit -A -m newhead
adding newhead
created new head
Trigger tags cache population by doing something that accesses tags info
$ hg log -G -T '{rev}:{node|short} {tags} {desc}\n'
@ 4:042eb6bfcc49 tip newhead
|
| o 3:c3cb30f2d2cd test2 tag
| |
| o 2:d75775ffbc6b test2 first
| |
| o 1:5f97d42da03f test tag
|/
o 0:55482a6fb4b1 test1 initial
$ cat .hg/cache/tags
4 042eb6bfcc4909bad84a1cbf6eb1ddf0ab587d41
3 c3cb30f2d2cd0aae008cc91a07876e3c5131fd22 b3bce87817fe7ac9dca2834366c1d7534c095cf1
55482a6fb4b1881fa8f746fd52cf6f096bb21c89 test1
d75775ffbc6bca1794d300f5571272879bd280da test2
Create some hidden changesets via a rebase and trigger tags cache
repopulation
$ hg -q rebase -s 1 -d 4
$ hg log -G -T '{rev}:{node|short} {tags} {desc}\n'
o 7:eb610439e10e tip test2 tag
|
o 6:7b4af00c3c83 first
|
o 5:43ac2a539b3c test tag
|
@ 4:042eb6bfcc49 newhead
|
o 0:55482a6fb4b1 test1 initial
.hgtags filenodes for hidden heads should be visible (issue4550)
(currently broken)
$ cat .hg/cache/tags
7 eb610439e10e0c6b296f97b59624c2e24fc59e30 b3bce87817fe7ac9dca2834366c1d7534c095cf1
55482a6fb4b1881fa8f746fd52cf6f096bb21c89 test1
d75775ffbc6bca1794d300f5571272879bd280da test2