Wed, 11 Mar 2015 15:54:11 -0700 record: make record use commit -i
Laurent Charignon <lcharignon@fb.com> [Wed, 11 Mar 2015 15:54:11 -0700] rev 24307
record: make record use commit -i
Fri, 13 Mar 2015 17:00:06 -0400 style: kill ersatz if-else ternary operators
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 13 Mar 2015 17:00:06 -0400] rev 24306
style: kill ersatz if-else ternary operators Although Python supports `X = Y if COND else Z`, this was only introduced in Python 2.5. Since we have to support Python 2.4, it was a very common thing to write instead `X = COND and Y or Z`, which is a bit obscure at a glance. It requires some intricate knowledge of Python to understand how to parse these one-liners. We change instead all of these one-liners to 4-liners. This was executed with the following perlism: find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \; I tweaked the following cases from the automatic Perl output: prev = (parents and parents[0]) or nullid port = (use_ssl and 443 or 80) cwd = (pats and repo.getcwd()) or '' rename = fctx and webutil.renamelink(fctx) or [] ctx = fctx and fctx or ctx self.base = (mapfile and os.path.dirname(mapfile)) or '' I also added some newlines wherever they seemd appropriate for readability There are probably a few ersatz ternary operators still in the code somewhere, lurking away from the power of a simple regex.
Fri, 13 Mar 2015 14:20:13 -0400 cvsps: use a different tiebreaker to avoid flaky test
Augie Fackler <raf@durin42.com> [Fri, 13 Mar 2015 14:20:13 -0400] rev 24305
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)))
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip