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)))
http://mercurial.selenic.com/bts/issue522
In the merge below, the file "foo" has the same contents in both
parents, but if we look at the file-level history, we'll notice that
the version in p1 is an ancestor of the version in p2. This test makes
sure that we'll use the version from p2 in the manifest of the merge
revision.
$ hg init
$ echo foo > foo
$ hg ci -qAm 'add foo'
$ echo bar >> foo
$ hg ci -m 'change foo'
$ hg backout -r tip -m 'backout changed foo'
reverting foo
changeset 2:4d9e78aaceee backs out changeset 1:b515023e500e
$ hg up -C 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ touch bar
$ hg ci -qAm 'add bar'
$ hg merge --debug
searching for copies back to rev 1
unmatched files in local:
bar
resolving manifests
branchmerge: True, force: False, partial: False
ancestor: bbd179dfa0a7, local: 71766447bdbb+, remote: 4d9e78aaceee
foo: remote is newer -> g
getting foo
updating: foo 1/1 files (100.00%)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg debugstate | grep foo
m 0 -2 unset foo
$ hg st -A foo
M foo
$ hg ci -m 'merge'
$ hg manifest --debug | grep foo
c6fc755d7e68f49f880599da29f15add41f42f5a 644 foo
$ hg debugindex foo
rev offset length ..... linkrev nodeid p1 p2 (re)
0 0 5 ..... 0 2ed2a3912a0b 000000000000 000000000000 (re)
1 5 9 ..... 1 6f4310b00b9a 2ed2a3912a0b 000000000000 (re)
2 14 5 ..... 2 c6fc755d7e68 6f4310b00b9a 000000000000 (re)