Wed, 11 Mar 2015 16:18:47 -0700 record: remove duplicated tests
Laurent Charignon <lcharignon@fb.com> [Wed, 11 Mar 2015 16:18:47 -0700] rev 24308
record: remove duplicated tests Since the record and commit -i commands are identical we simplify record's test to just cover the help message and minimal smoke testing.
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)))
Sat, 14 Mar 2015 22:34:27 +0900 templates: fix "log -q" output of default style stable
Yuya Nishihara <yuya@tcha.org> [Sat, 14 Mar 2015 22:34:27 +0900] rev 24304
templates: fix "log -q" output of default style It was changed at 0ded0f0b1c04 unintentionally due to name conflicts.
Fri, 13 Mar 2015 17:55:04 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 13 Mar 2015 17:55:04 -0500] rev 24303
merge with stable
Thu, 12 Mar 2015 22:59:52 -0400 subrepo: replace 'ctx._repo' with 'ctx.repo()'
Matt Harbison <matt_harbison@yahoo.com> [Thu, 12 Mar 2015 22:59:52 -0400] rev 24302
subrepo: replace 'ctx._repo' with 'ctx.repo()'
Thu, 12 Mar 2015 22:55:35 -0400 files: replace 'ctx._repo' with 'ctx.repo()'
Matt Harbison <matt_harbison@yahoo.com> [Thu, 12 Mar 2015 22:55:35 -0400] rev 24301
files: replace 'ctx._repo' with 'ctx.repo()'
Thu, 12 Mar 2015 22:54:53 -0400 context: add a repo accessor
Matt Harbison <matt_harbison@yahoo.com> [Thu, 12 Mar 2015 22:54:53 -0400] rev 24300
context: add a repo accessor There are 29 instances of 'ctx._repo' in the code, so make the ability to access more official.
Thu, 12 Mar 2015 21:49:20 -0400 test-histedit-edit.t: demonstrate qnew fails during a histedit (issue4366)
Augie Fackler <augie@google.com> [Thu, 12 Mar 2015 21:49:20 -0400] rev 24299
test-histedit-edit.t: demonstrate qnew fails during a histedit (issue4366) This was accidentally fixed by other work, but given that it's been broken in the past, I'd like to have a test defending us against regressions in this area, especially as we add more functionality to histedit.
Thu, 12 Mar 2015 18:18:29 -0700 lazymanifest: make __iter__ generate filenames, not 3-tuples
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Mar 2015 18:18:29 -0700] rev 24298
lazymanifest: make __iter__ generate filenames, not 3-tuples The _lazymanifest type(s) behave very much like a sorted dict with filenames as keys and (nodeid, flags) as values. It therefore seems surprising that its __iter__ generates 3-tuples of (path, nodeid, flags). Let's make it match dict's behavior of generating the keys instead, and add a new iterentries method for the 3-tuples. With this change, the "x" in "if x in lm" and "for x in lm" now have the same type (a filename string).
Thu, 12 Mar 2015 18:53:44 -0700 lazymanifest: fix pure hg iterkeys()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Mar 2015 18:53:44 -0700] rev 24297
lazymanifest: fix pure hg iterkeys() I broke pure hg when I just added iterkeys() to the native version in 2b7ab29627fd. I forgot to make the pure version sorted. Fix it.
Fri, 13 Mar 2015 21:18:59 +0900 hgweb: prevent loading style map from directories other than specified paths stable
Yuya Nishihara <yuya@tcha.org> [Fri, 13 Mar 2015 21:18:59 +0900] rev 24296
hgweb: prevent loading style map from directories other than specified paths A style name should not contain "/", "\", "." and "..". Otherwise, templates could be loaded from outside of the specified templates directory by invalid ?style= parameter. hgweb should not allow such requests. This change means subdir/name is also rejected.
Wed, 11 Mar 2015 13:46:15 -0700 lazymanifest: add iterkeys() method
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Mar 2015 13:46:15 -0700] rev 24295
lazymanifest: add iterkeys() method So we don't have to iteratate over (path, node, flags) tuples only to throw away the node and flags.
Wed, 11 Mar 2015 13:15:26 -0700 lazymanifest: extract function for iterating to next line
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Mar 2015 13:15:26 -0700] rev 24294
lazymanifest: extract function for iterating to next line This will soon be reused by keys iterator.
Wed, 11 Mar 2015 13:35:34 -0700 lazymanifest: fail if path or hash strings cannot be created
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Mar 2015 13:35:34 -0700] rev 24293
lazymanifest: fail if path or hash strings cannot be created While generating (path, hash, flags), we fail if flags cannot be created. We should also fail if path or hash cannot be created.
Wed, 11 Mar 2015 08:28:56 -0700 manifest: rewrite find(node, f) in terms of read(node)
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Mar 2015 08:28:56 -0700] rev 24292
manifest: rewrite find(node, f) in terms of read(node) Since find() now always works with a full manifest, we can simplify by calling read() to give us that manifest. That way, we also populate the manifest cache. However, now that we no longer parse the manifest text into a Python type (thanks, lazymanifest/Augie), the cost of parsing (scanning for newlines, really) is small enough that it seems generally drowned by revlog reading.
Thu, 26 Feb 2015 22:54:13 +0900 ssl: load CA certificates from system's store by default on Python 2.7.9
Yuya Nishihara <yuya@tcha.org> [Thu, 26 Feb 2015 22:54:13 +0900] rev 24291
ssl: load CA certificates from system's store by default on Python 2.7.9 This will make it easy to manage in-house CA certificates, which are often used in corporate environment and installed into the Windows' certs store. Unlike Apple python, the dummycert trick isn't necessary on Python 2.7.9. The default web.cacerts will be set as follows: environment web.cacerts behavior ------------- ----------- ----------------------------------------- Apple Python dummycert fall back to system's store Python 2.7.8 '!' never use CA certs (show warning instead) Python 2.7.9+ None load CA certs from system's store
Wed, 04 Mar 2015 23:27:04 +0900 ssl: set explicit symbol "!" to web.cacerts to disable SSL verification (BC)
Yuya Nishihara <yuya@tcha.org> [Wed, 04 Mar 2015 23:27:04 +0900] rev 24290
ssl: set explicit symbol "!" to web.cacerts to disable SSL verification (BC) The next patch will enable verification by using the system's CA store if possible, which means we would have to distinguish None (=use default) from '' (=--insecure). This smells bug-prone and provides no way to override web.cacerts to forcibly use the system's store by --config argument. This patch changes the meaning of web.cacerts as follows: value behavior ------- --------------------------------------- None/'' use default '!' never use CA certs (set by --insecure) <path> verify by the specified CA certificates Values other than <path> are for internal use and therefore undocumented.
Wed, 04 Mar 2015 22:41:48 +0900 test-https: enable dummycert test only if Apple python is used (issue4500)
Yuya Nishihara <yuya@tcha.org> [Wed, 04 Mar 2015 22:41:48 +0900] rev 24289
test-https: enable dummycert test only if Apple python is used (issue4500) The dummycert trick works only if Python is linked to Apple's patched OpenSSL.
Wed, 04 Mar 2015 22:27:01 +0900 ssl: extract function that returns dummycert path on Apple python
Yuya Nishihara <yuya@tcha.org> [Wed, 04 Mar 2015 22:27:01 +0900] rev 24288
ssl: extract function that returns dummycert path on Apple python This function will be the condition to switch DISABLEOSXDUMMYCERT in test-https.t.
Wed, 11 Mar 2015 21:36:48 -0700 largefiles: don't create chain of __contains__ calls
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Mar 2015 21:36:48 -0700] rev 24287
largefiles: don't create chain of __contains__ calls Matt Harbison pointed out that my recent 2720f967a7b1 might cause __contains__ to continously get replaced by another version that calls itself, since the manifest instance returned by the super method is always the same instance due to @propertycache. He also suggested replacing the class instead, as is done with the context class in the surrounding code. Do so.
Thu, 12 Mar 2015 09:06:45 -0700 lazymanifest: don't depend on printf's 'hh' format to work
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Mar 2015 09:06:45 -0700] rev 24286
lazymanifest: don't depend on printf's 'hh' format to work Where we convert a 20-byte binary to a 40-byte hex string in lazymanifest_setitem(), we use sprintf("%02hhx", hash[i]). As Matt Harbison found out, 'hh' seems to be ignored on some platforms (Visual Studio?). If char is signed on such platforms, the value gets sign-extended as it gets promoted into an int when passed into the variadic sprintf(). The resulting integer value will then be printed with leading f's (14 of them on 64-bit systems), since the '2' in the format string indicates only minimum number of characters. This is both incorrect and runs the risk of writing outside of allocated memory (as Matt reported). To fix, let's cast the value to unsigned char before passing it to sprintf(). Also drop the poorly supported 'hh' formatting that now becomes unnecessary.
Wed, 11 Mar 2015 17:53:50 -0700 bundle2: test hooking using the new transaction-level hook
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 11 Mar 2015 17:53:50 -0700] rev 24285
bundle2: test hooking using the new transaction-level hook There is no strong reason to keep a bundle2-level hook as we can use the transaction-level hook.
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip