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 > echo.py <<EOF
> #!/usr/bin/env python
> import os, sys
> try:
> import msvcrt
> msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
> msvcrt.setmode(sys.stderr.fileno(), os.O_BINARY)
> except ImportError:
> pass
>
> for k in ('HG_FILE', 'HG_MY_ISLINK', 'HG_OTHER_ISLINK', 'HG_BASE_ISLINK'):
> print k, os.environ[k]
> EOF
Create 2 heads containing the same file, once as
a file, once as a link. Bundle was generated with:
# hg init t
# cd t
# echo a > a
# hg ci -qAm t0 -d '0 0'
# echo l > l
# hg ci -qAm t1 -d '1 0'
# hg up -C 0
# ln -s a l
# hg ci -qAm t2 -d '2 0'
# echo l2 > l2
# hg ci -qAm t3 -d '3 0'
$ hg init t
$ cd t
$ hg -q pull "$TESTDIR/bundles/test-merge-symlinks.hg"
$ hg up -C 3
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Merge them and display *_ISLINK vars
merge heads
$ hg merge --tool="python ../echo.py"
merging l
HG_FILE l
HG_MY_ISLINK 1
HG_OTHER_ISLINK 0
HG_BASE_ISLINK 0
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Test working directory symlink bit calculation wrt copies,
especially on non-supporting systems.
merge working directory
$ hg up -C 2
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg copy l l2
$ HGMERGE="python ../echo.py" hg up 3
merging l2
HG_FILE l2
HG_MY_ISLINK 1
HG_OTHER_ISLINK 0
HG_BASE_ISLINK 0
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
$ cd ..