Sat, 08 Aug 2015 00:35:37 -0700 changegroup: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Aug 2015 00:35:37 -0700] rev 25921
changegroup: use absolute_import
Sat, 08 Aug 2015 00:36:35 -0700 bundlerepo: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Aug 2015 00:36:35 -0700] rev 25920
bundlerepo: use absolute_import
Fri, 07 Aug 2015 19:54:08 -0700 bundle2: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 07 Aug 2015 19:54:08 -0700] rev 25919
bundle2: use absolute_import
Fri, 07 Aug 2015 19:51:55 -0700 branchmap: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 07 Aug 2015 19:51:55 -0700] rev 25918
branchmap: use absolute_import
Fri, 07 Aug 2015 19:49:21 -0700 bookmarks: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 07 Aug 2015 19:49:21 -0700] rev 25917
bookmarks: use absolute_import
Fri, 07 Aug 2015 19:47:49 -0700 archival: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 07 Aug 2015 19:47:49 -0700] rev 25916
archival: use absolute_import
Fri, 07 Aug 2015 19:45:48 -0700 ancestor: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 07 Aug 2015 19:45:48 -0700] rev 25915
ancestor: use absolute_import A few months ago, import-checker.py was taught to enforce a more well-defined import style for files with absolute_import. However, we stopped short of actually converting source files to use absolute_import because of problems with certain files. Investigation revealed the following problems with switching to absolute_import universally: 1) import cycles result in import failure on Python 2.6 2) undetermined way to import C/pure modules While these problems need to be solved, they can be put off. This patch starts a series of converting files to absolute_import that won't exhibit any of the aforementioned problems.
Wed, 05 Aug 2015 14:21:46 -0400 discovery: always use batching now that all peers support batching
Augie Fackler <augie@google.com> [Wed, 05 Aug 2015 14:21:46 -0400] rev 25914
discovery: always use batching now that all peers support batching Some peers will transparently downgrade batched requests to non-batched ones, but that simplifies code for everyone using batching.
Wed, 05 Aug 2015 14:15:17 -0400 wireproto: make wirepeer look-before-you-leap on batching
Augie Fackler <augie@google.com> [Wed, 05 Aug 2015 14:15:17 -0400] rev 25913
wireproto: make wirepeer look-before-you-leap on batching This means that users of request batching don't need to worry themselves with capability checking. Instead, they can just use batching, and if the remote server doesn't support batching for some reason the wirepeer code will transparently un-batch the requests. This will allow for some slight simplification in a handful of places. Prior to this change, largefiles would have been silently broken against a server which did not support batching.
Wed, 05 Aug 2015 14:51:34 -0400 batching: migrate basic noop batching into peer.peer
Augie Fackler <augie@google.com> [Wed, 05 Aug 2015 14:51:34 -0400] rev 25912
batching: migrate basic noop batching into peer.peer "Real" batching only makes sense for wirepeers, but it greatly simplifies the clients of peer instances if they can be ignorant to actual batching capabilities of that peer. By moving the not-really-batched batching code into peer.peer, all peer instances now work with the batching API, thus simplifying users. This leaves a couple of name forwards in wirepeer.py. Originally I had planned to clean those up, but it kind of unclarifies other bits of code that want to use batching, so I think it makes sense for the names to stay exposed by wireproto. Specifically, almost nothing is currently aware of peer (see largefiles.proto for an example), so making them be aware of the peer module *and* the wireproto module seems like some abstraction leakage. I *think* the right long-term fix would actually be to make wireproto an implementation detail that clients wouldn't need to know about, but I don't really know what that would entail at the moment. As far as I'm aware, no clients of batching in third-party extensions will need updating, which is nice icing.
Thu, 06 Aug 2015 22:54:28 -0700 parsers: fix memory leak in compute_phases_map_sets stable
Laurent Charignon <lcharignon@fb.com> [Thu, 06 Aug 2015 22:54:28 -0700] rev 25911
parsers: fix memory leak in compute_phases_map_sets PySet_Add increments the reference of the added object to the set, see: https://hg.python.org/cpython/file/2.6/Objects/setobject.c#l379 Before this patch we were forgetting to decrement the reference count after adding objects to the phaseset. This patch fixes the issue and makes the reference count right so that these objects can be properly garbage collected.
Mon, 03 Aug 2015 06:13:05 -0700 histedit: do not stay on a cleaned nodes on abort
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 06:13:05 -0700] rev 25910
histedit: do not stay on a cleaned nodes on abort There is case where nodes are neither in tmpnodes nor leaf but still get removed. For example, if you used the "edit" action, made a commit and run --abort. The commit you made is not tracked by histedit, yet it will likely be cleaned up with its parent. The commit may not tracked because no replacements computations are done in the --abort case.
Mon, 03 Aug 2015 06:11:45 -0700 histedit: also update away from tmpnodes
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 06:11:45 -0700] rev 25909
histedit: also update away from tmpnodes The working copy may be on a tmpnodes, we need to update away before it is stripped from the repository.
Mon, 03 Aug 2015 06:08:37 -0700 histedit: use revset to check if we need to update during abort
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 06:08:37 -0700] rev 25908
histedit: use revset to check if we need to update during abort The for loop is already quite more complicated than necessary and we are about to add some logic. Instead, we use a simple revset. Revset laziness should provide us with similar performance.
Mon, 03 Aug 2015 05:57:45 -0700 histedit: remove useless 'else' clause
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 05:57:45 -0700] rev 25907
histedit: remove useless 'else' clause This 'else: pass' clause have no effect. We drop it for clarity.
Fri, 31 Jul 2015 15:46:49 -0700 histedit: make cleanupnode more robust
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 31 Jul 2015 15:46:49 -0700] rev 25906
histedit: make cleanupnode more robust The goal of this function is to strip content out of the repository. We do not really care if this content is visible or cleanup node not and we should proceed anyway. None of the internal actions are subject to this, however, a third party extension running arbitrary commands during histedit is affected by this.
Wed, 29 Jul 2015 13:21:03 -0700 convert: fix git convert using servers branches
Durham Goode <durham@fb.com> [Wed, 29 Jul 2015 13:21:03 -0700] rev 25905
convert: fix git convert using servers branches The conversion from git to hg was reading the remote branch list directly from the origin server. If the origin's branch had moved forward since the last git fetch, it would return a git hash which didn't exist locally, and therefore the branch was not converted. This changes it to rely on the local repo's refs/remotes list of branches instead, so it's completely cut off from the server.
Sat, 24 Jan 2015 22:28:14 +0900 revrange: drop old-style parser in favor of revset (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 24 Jan 2015 22:28:14 +0900] rev 25904
revrange: drop old-style parser in favor of revset (API) Now revset can parse nullary ":" operator and existing "foo+bar" tags, we don't need the old-style parser. This means scmutil.revsingle(), revpair() and revrange() no longer accept a binary nodeid. An integer revision is still allowed as it isn't ambiguous.
Sun, 15 Mar 2015 14:45:26 +0900 tag: do not pass binary nullid to scmutil.revsingle()
Yuya Nishihara <yuya@tcha.org> [Sun, 15 Mar 2015 14:45:26 +0900] rev 25903
tag: do not pass binary nullid to scmutil.revsingle() Future patches will remove the old-style parser that happen to accept a binary nodeid. A binary nodeid shouldn't be passed to scmutil.revrange() because it is ambiguous. For example, bin('20' * 19 + '30') is valid binary nodeid, but it can also be parsed as a revset expression, '0'.
Sat, 18 Jul 2015 23:30:17 +0900 revset: port parsing rule of old-style ranges from scmutil.revrange()
Yuya Nishihara <yuya@tcha.org> [Sat, 18 Jul 2015 23:30:17 +0900] rev 25902
revset: port parsing rule of old-style ranges from scmutil.revrange() The old-style parser will be removed soon.
Sat, 18 Jul 2015 23:02:18 +0900 debugrevspec: pass lookup function to visualize fallback mechanism
Yuya Nishihara <yuya@tcha.org> [Sat, 18 Jul 2015 23:02:18 +0900] rev 25901
debugrevspec: pass lookup function to visualize fallback mechanism The next patch will move the exceptional parsing of old-style ranges to revset.tokenize(). This patch will allow us to see the result tree. Note that the parsing result of '-a-b-c-' is incorrect at this changeset. It will be fixed soon.
Mon, 03 Aug 2015 20:34:36 +0100 help: fix typo familar -> familiar stable
Javi Merino <merino.jav@gmail.com> [Mon, 03 Aug 2015 20:34:36 +0100] rev 25900
help: fix typo familar -> familiar
Sun, 02 Aug 2015 19:18:35 +0800 highlight: exit early on textual and unknown files (issue3005)
Anton Shestakov <av6@dwimlabs.net> [Sun, 02 Aug 2015 19:18:35 +0800] rev 25899
highlight: exit early on textual and unknown files (issue3005) When highlight extension encountered files that pygments didn't recognize, it used to fall back to text lexer. Also, pygments uses TextLexer for .txt files. This lexer is noop by design. On bigger files, however, doing the noop highlighting resulted in noticeable extra CPU work and memory usage: to show a 1 MB text file, hgweb required about 0.7s more (on top of ~3.8s, Q8400) and consumed about 100 MB of RAM more (on top of ~150 MB). Let's just exit the function when it's clear that nothing will be highlighted. Due to how this pygmentize function works (it modifies the template in-place), we can just return from it and everything else will work as if highlight extension wasn't enabled.
Mon, 03 Aug 2015 14:16:51 -0700 histedit: extract a simpler function to process replacement on abort
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 14:16:51 -0700] rev 25898
histedit: extract a simpler function to process replacement on abort The process replacement is building a full mapping to allow moving bookmarks and creating obsolescence marker. We do not need the full logic for abort so we extract it. It will be useful as abort is missing some data about the replacement and can crash when third party extensions push it a bit too far.
Mon, 03 Aug 2015 14:05:42 -0700 merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 14:05:42 -0700] rev 25897
merge with stable
Mon, 20 Jul 2015 13:39:25 -0700 exchange: fix dead assignment
Martin von Zweigbergk <martinvonz@google.com> [Mon, 20 Jul 2015 13:39:25 -0700] rev 25896
exchange: fix dead assignment The assignment of the value from bundle2.processbundle() to 'r' is unused. It is currently the same as its third argument (if given), and since that argument may eventually go away (according to the method's docstring), let's reassign the return value to 'op' instead to better prepare for that.
Mon, 20 Jul 2015 13:35:19 -0700 exchange: s/phase/bookmark/ in _pushb2bookmarks()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 20 Jul 2015 13:35:19 -0700] rev 25895
exchange: s/phase/bookmark/ in _pushb2bookmarks()
Fri, 31 Jul 2015 15:11:07 -0700 histedit: backout ebb5bb9bc32e stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 31 Jul 2015 15:11:07 -0700] rev 25894
histedit: backout ebb5bb9bc32e The faulty changeset use obsolescence marker to roll the repository back on --abort. This is a problematic approach because --abort should be as close as an actually transaction rollback as possible stripping all created data from the repository (cf `hg rebase --abort` stripping all created changesets). Instead ebb5bb9bc32e made all content created during the aborted histedit still available in the repository adding obsolescence marker to make them hidden. This will cause trouble to evolution user as a re-run of the same histedit (with success) will likely result in the very same node to be "recreated" while obsolescence marker would be in place for them. And canceling an obsoletion is still a fairly complicated process. This also rollback using obsmarkers instead of strip to clean up temporary node on successful histedit run because the two change were not split in separated changeset. Rolling that part back does not have significant consequence a will have to be resubmitted independently
Sun, 02 Aug 2015 21:56:38 -0700 test-bookmarks.t: avoid nested repo
Siddharth Agarwal <sid0@fb.com> [Sun, 02 Aug 2015 21:56:38 -0700] rev 25893
test-bookmarks.t: avoid nested repo This is (a) pretty unnecessary and (b) breaks tests for the third-party hgwatchman extension, which doesn't support nested repos.
Sun, 02 Aug 2015 12:16:19 +0900 revlog: remove unused shaoffset constants
Yuya Nishihara <yuya@tcha.org> [Sun, 02 Aug 2015 12:16:19 +0900] rev 25892
revlog: remove unused shaoffset constants Call sites were removed at 61c9bc3da402, "revlog: remove lazy index".
Sun, 02 Aug 2015 01:14:11 +0900 revlog: correct comment about size of v0 index format
Yuya Nishihara <yuya@tcha.org> [Sun, 02 Aug 2015 01:14:11 +0900] rev 25891
revlog: correct comment about size of v0 index format
Mon, 03 Aug 2015 11:34:27 -0700 merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 11:34:27 -0700] rev 25890
merge with stable
(0) -10000 -3000 -1000 -300 -100 -50 -32 +32 +50 +100 +300 +1000 +3000 +10000 tip