Mon, 18 Jul 2016 22:25:09 +0200 rbc: fix superfluous rebuilding from scratch - don't abuse self._rbcnamescount stable
Mads Kiilerich <madski@unity3d.com> [Mon, 18 Jul 2016 22:25:09 +0200] rev 29615
rbc: fix superfluous rebuilding from scratch - don't abuse self._rbcnamescount The code used self._rbcnamescount as if it was the length of self._names ... but actually it is just the number of good entries on disk. This caused the cache to be populated inefficiently. In some cases very inefficiently. Instead of checking the length before lookup, just try a lookup in self._names - that is also in most cases faster. Comments and debug messages are tweaked to help understanding the issue and the fix.
Mon, 18 Jul 2016 22:23:44 +0200 rbc: test case for incorrect and too aggressive invalidation of invalid caches stable
Mads Kiilerich <madski@unity3d.com> [Mon, 18 Jul 2016 22:23:44 +0200] rev 29614
rbc: test case for incorrect and too aggressive invalidation of invalid caches
Tue, 19 Jul 2016 10:15:35 -0700 util: better handle '-' in version string (issue5302) stable
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 19 Jul 2016 10:15:35 -0700] rev 29613
util: better handle '-' in version string (issue5302) versiontuple() was previously only splitting on '+' and strings like "3.9-rc" were causing it to misreport the version as (3, None). By splitting on either '+' or '-' we can handle our version strings with "-rc" in them.
Tue, 19 Jul 2016 11:00:32 -0500 convert: update use of deprecated bzrlib property stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Tue, 19 Jul 2016 11:00:32 -0500] rev 29612
convert: update use of deprecated bzrlib property The inventory property was deprecated in favor of root_inventory in bzr 2.5.0. Current version is 2.7.0. I noticed this when testing locally on Python 2.6.9, which has warnings turned on by default. The failure that occurs without this patch can be seen on Python 2.7 by running with warnings enabled: $ PYTHONWARNINGS=::DeprecationWarning make 'test-convert-bzr*'
Tue, 19 Jul 2016 21:16:44 +0900 hghave: fix typo of sslutil.supportedprotocols stable
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Jul 2016 21:16:44 +0900] rev 29611
hghave: fix typo of sslutil.supportedprotocols
Tue, 19 Jul 2016 03:29:53 -0700 rebase: turn rebase revs into set before filtering obsolete stable
Simon Farnsworth <simonfar@fb.com> [Tue, 19 Jul 2016 03:29:53 -0700] rev 29610
rebase: turn rebase revs into set before filtering obsolete When the inhibit extension from mutable-history is enabled, it attempts to iterate over the rebaseset to prevent the nodes being rebased from being marked obsolete. This happens at the same time as rebase's _filterobsoleterevs function trying to iterate over the rebaseset to figure out which ones are obsolete. The two of these iterating over the same revset generatorset cause a 'generator already executing' exception. This is probably a flaw in the revset implementation, since iterating over the same set twice should be supported. This regression was introduced in 5d16ebe7b14, since it changed _filterobsoleterevs to be called before the rebaseset was turned into a set(). For now let’s just make the rebaseset an actual set again before calling that function. This was caught by the inhibit tests. The relevant call stack from test-inhibit.t: File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 285, in _preparenewrebase obsrevs = _filterobsoleterevs(self.repo, rebaseset) File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/inhibit.py", line 197, in _filterobsoleterevswrap r = orig(repo, rebasesetrevs, *args, **kwargs) File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 1380, in _filterobsoleterevs return set(r for r in revs if repo[r].obsolete()) File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 1380, in <genexpr> return set(r for r in revs if repo[r].obsolete()) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3079, in _iterordered val2 = next(iter2) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3417, in gen yield nextrev() File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3424, in _consumegen for item in self._gen: File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 71, in iterate cl = repo.changelog File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 319, in changelog revs = filterrevs(unfi, self.filtername) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 261, in filterrevs repo.filteredrevcache[filtername] = func(repo.unfiltered()) File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/directaccess.py", line 65, in _computehidden hidden = repoview.filterrevs(repo, 'visible') File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 261, in filterrevs repo.filteredrevcache[filtername] = func(repo.unfiltered()) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 175, in computehidden hideable = hideablerevs(repo) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 33, in hideablerevs return obsolete.getrevs(repo, 'obsolete') File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/obsolete.py", line 1097, in getrevs repo.obsstore.caches[name] = cachefuncs[name](repo) File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/inhibit.py", line 255, in _computeobsoleteset if getrev(n) not in blacklist: File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3264, in __contains__ return x in self._r1 or x in self._r2 File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3348, in __contains__ for l in self._consumegen(): File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3424, in _consumegen for item in self._gen: ValueError: generator already executing
Mon, 18 Jul 2016 15:59:08 +0100 commandserver: update comment about setpgid stable
Jun Wu <quark@fb.com> [Mon, 18 Jul 2016 15:59:08 +0100] rev 29609
commandserver: update comment about setpgid Now setpgid has 2 main purposes: better handling for terminal-generated SIGTSTP, SIGINT, and process-exit-generated SIGHUP. Update the comment to explain things more clearly.
Sun, 17 Jul 2016 22:55:47 +0100 chg: forward SIGINT, SIGHUP to process group stable
Jun Wu <quark@fb.com> [Sun, 17 Jul 2016 22:55:47 +0100] rev 29608
chg: forward SIGINT, SIGHUP to process group These signals are meant to send to a process group, instead of a single process: SIGINT is usually emitted by the terminal and sent to the process group. SIGHUP usually happens to a process group if termination of a process causes that process group to become orphaned. Before this patch, chg will only forward these signals to the single server process. This patch changes it to the server process group. This will allow us to properly kill processes started by the forked server process, like a ssh process. The behavior difference can be observed by setting SSH_ASKPASS to a dummy script doing "sleep 100" and then run "chg push ssh://dest-need-password-auth". Before this patch, the first Ctrl+C will kill the hg process while ssh-askpass and ssh will remain alive. This patch will make sure they are killed properly.
Mon, 18 Jul 2016 23:31:51 -0500 Added signature for changeset 519bb4f9d3a4 stable
Matt Mackall <mpm@selenic.com> [Mon, 18 Jul 2016 23:31:51 -0500] rev 29607
Added signature for changeset 519bb4f9d3a4
Mon, 18 Jul 2016 23:31:50 -0500 Added tag 3.9-rc for changeset 519bb4f9d3a4 stable
Matt Mackall <mpm@selenic.com> [Mon, 18 Jul 2016 23:31:50 -0500] rev 29606
Added tag 3.9-rc for changeset 519bb4f9d3a4
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip