Fri, 04 Jan 2019 17:54:18 +0100 discovery: improve partial discovery documentation
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 17:54:18 +0100] rev 41172
discovery: improve partial discovery documentation The older documentation could be improved.
Fri, 28 Dec 2018 03:59:38 +0100 discovery: add a simple `addinfo` method
Boris Feld <boris.feld@octobus.net> [Fri, 28 Dec 2018 03:59:38 +0100] rev 41171
discovery: add a simple `addinfo` method The method can directly process a sample result. This makes the main code simpler to follow.
Fri, 28 Dec 2018 03:48:00 +0100 discovery: move missing tracking inside the partialdiscovery object
Boris Feld <boris.feld@octobus.net> [Fri, 28 Dec 2018 03:48:00 +0100] rev 41170
discovery: move missing tracking inside the partialdiscovery object This is the final set that we need to track to have a fully up to date information within the object.
Fri, 28 Dec 2018 03:39:43 +0100 discovery: add a `iscomplete` method to the `partialdiscovery` object
Boris Feld <boris.feld@octobus.net> [Fri, 28 Dec 2018 03:39:43 +0100] rev 41169
discovery: add a `iscomplete` method to the `partialdiscovery` object The method is used by higher level logic to know if the initial discovery question has been answered.
Fri, 28 Dec 2018 03:34:23 +0100 discovery: update undecided from common directly within partialdiscovery
Boris Feld <boris.feld@octobus.net> [Fri, 28 Dec 2018 03:34:23 +0100] rev 41168
discovery: update undecided from common directly within partialdiscovery The object knows when there are changes in the "common" set, so it is a good place to update the undecided set.
Fri, 28 Dec 2018 03:23:37 +0100 discovery: move undecided set on the partialdiscovery
Boris Feld <boris.feld@octobus.net> [Fri, 28 Dec 2018 03:23:37 +0100] rev 41167
discovery: move undecided set on the partialdiscovery To initialize it, we need to know the discovery target. This commit only move the set on the `partialdiscovery` object, later changeset will take advantage of it.
Wed, 09 Jan 2019 15:34:24 -0800 histedit: use context manager for locks
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Jan 2019 15:34:24 -0800] rev 41166
histedit: use context manager for locks Differential Revision: https://phab.mercurial-scm.org/D5542
Wed, 09 Jan 2019 15:32:26 -0800 histedit: drop unused constructor arguments (API)
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Jan 2019 15:32:26 -0800] rev 41165
histedit: drop unused constructor arguments (API) All in-tree callers pass a repo and nothing else. Differential Revision: https://phab.mercurial-scm.org/D5541
Sat, 05 Jan 2019 19:50:30 -0500 phabricator: teach {phabreview} to work without --amend
Matt Harbison <matt_harbison@yahoo.com> [Sat, 05 Jan 2019 19:50:30 -0500] rev 41164
phabricator: teach {phabreview} to work without --amend There's some possibility of this being wrong (e.g. if the url config was changed). But commit messages can be amended too, so that isn't bulletproof either. Having something seems better than just returning None.
Sat, 05 Jan 2019 15:20:33 -0500 phabricator: warn if unable to amend, instead of aborting after posting
Matt Harbison <matt_harbison@yahoo.com> [Sat, 05 Jan 2019 15:20:33 -0500] rev 41163
phabricator: warn if unable to amend, instead of aborting after posting There was a divergence in behavior here between obsolete and strip based amending. I first noticed the abort when testing outside of the test harness, but then had trouble recreating it here after reverting the code changes. It turns out, strip based amend was successfully amending the public commit after it was posted! It looks like the protection is in the `commit --amend` command, not in the underlying code that it calls. I considered doing a preflight check and aborting. But the locks are only acquired at the end, if amending, and this is too large a section of code to be wrapped in a maybe-it's-held-or-not context manager for my tastes. Additionally, some people do post-push reviews, and amending is the default behavior, so they shouldn't see a misleading error message. The lack of a 'Differential Revision' entry in the commit message breaks a {phabreview} test, so it had to be partially conditionalized.
Thu, 10 Jan 2019 04:35:48 +0100 discovery: re-adjust a conditional wrongly changed
Boris Feld <boris.feld@octobus.net> [Thu, 10 Jan 2019 04:35:48 +0100] rev 41162
discovery: re-adjust a conditional wrongly changed In 71b0db4fa027 we updated this conditional to `<=`. As Yuya Nishihara pointed out, this was wrong.
Mon, 07 Jan 2019 18:43:10 -0500 cleanup: stop including thirdparty.cbor in builds
Augie Fackler <augie@google.com> [Mon, 07 Jan 2019 18:43:10 -0500] rev 41161
cleanup: stop including thirdparty.cbor in builds Differential Revision: https://phab.mercurial-scm.org/D5524
Mon, 07 Jan 2019 18:41:53 -0500 tests: get access to thirdparty.cbor without requiring it to be installed
Augie Fackler <augie@google.com> [Mon, 07 Jan 2019 18:41:53 -0500] rev 41160
tests: get access to thirdparty.cbor without requiring it to be installed This makes the test a noop when run from a tarball, but in return we can stop shipping a library we don't use. Differential Revision: https://phab.mercurial-scm.org/D5523
Mon, 07 Jan 2019 17:19:19 -0500 tests: add simplestorerepo to test-check-interfaces.py
Augie Fackler <augie@google.com> [Mon, 07 Jan 2019 17:19:19 -0500] rev 41159
tests: add simplestorerepo to test-check-interfaces.py I'm not thrilled with this, but it'll help avoid future bitrot. Differential Revision: https://phab.mercurial-scm.org/D5521
Mon, 07 Jan 2019 16:50:23 -0500 simplestorerepo: migrate to in-hg CBOR code
Augie Fackler <augie@google.com> [Mon, 07 Jan 2019 16:50:23 -0500] rev 41158
simplestorerepo: migrate to in-hg CBOR code This is the only use of thirdparty.cbor outside of a test-* file, so it felt worthwhile to clean it up. Differential Revision: https://phab.mercurial-scm.org/D5520
Mon, 07 Jan 2019 18:22:20 -0500 simplestorerepo: minimal changes required to get this mostly working again
Augie Fackler <augie@google.com> [Mon, 07 Jan 2019 18:22:20 -0500] rev 41157
simplestorerepo: minimal changes required to get this mostly working again I was going to change this code's use of CBOR to use our in-house CBOR code, but discovered it's been broken for a while. This messy change gets it back to a point where it mostly works, I think roughly as well as it ever did. Should we keep this and fix it up the rest of the way, or dump it in favor of the sqlite store? Would this be a good jumping-off point for some sort of union store that could facilitate a cleanup in remotefilelog? Differential Revision: https://phab.mercurial-scm.org/D5519
Tue, 04 Dec 2018 11:22:31 -0800 perfrevlogwrite: use progress helper on modern hg
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Dec 2018 11:22:31 -0800] rev 41156
perfrevlogwrite: use progress helper on modern hg Differential Revision: https://phab.mercurial-scm.org/D5372
Tue, 08 Jan 2019 14:19:51 -0800 merge: make local file storage in the .hg/merge directory extensible
Daniel Ploch <dploch@google.com> [Tue, 08 Jan 2019 14:19:51 -0800] rev 41155
merge: make local file storage in the .hg/merge directory extensible This is similar to remotefilelog's 'getlocalkey' method, which must be overridden by systems which rely on full path names for access control purposes. Differential Revision: https://phab.mercurial-scm.org/D5534
Tue, 08 Jan 2019 14:31:22 -0800 context: schedule file prefetch before comparing for cleanliness
Kyle Lippincott <spectral@google.com> [Tue, 08 Jan 2019 14:31:22 -0800] rev 41154
context: schedule file prefetch before comparing for cleanliness When using a system like remotefilelog, we can occasionally run into scenarios where the local content cache does not have the data we need to perform these comparisons. These will be fetched on-demand, but individually; if the remotefilelog server isn't extremely low latency, the runtime of the command becomes dominated by the multiple getfile requests for individual files. By performing the prefetch, we can download these files in bulk, and save server resources and many network roundtrips. Differential Revision: https://phab.mercurial-scm.org/D5532
Wed, 12 Dec 2018 16:26:58 +0300 manifest: convert a recursive function to iterative one using stacks
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 12 Dec 2018 16:26:58 +0300] rev 41153
manifest: convert a recursive function to iterative one using stacks I am debugging a memory issue from yesterday where `hg update` goes upto taking 22GB of memory on our internal treemanifest repository. This is an interesting function and I saw memory consumption increasing while this function was running. It's sometimes hard to understand a recursive function and also the profile won't show you actual operations which took time, rather it will show you the function again and again in profile. I am yet to notice any memory consumption decrease with this patch, but I believe this will help like in making this a generator. Differential Revision: https://phab.mercurial-scm.org/D5413
Sun, 23 Dec 2018 02:01:35 +0530 obsutil: fix the issue5686
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 23 Dec 2018 02:01:35 +0530] rev 41152
obsutil: fix the issue5686 While traversing the obsolescence graph to find the successors sets of csets: In its 4th case (read comments of obsutil.successorssets to see all 4 cases) where we know successors sets of all direct successors of CURRENT, we were just missing a condition to filter out the case when a cset is pruned. And without this condition (that this patch added) it was making a whole successor set to [] just because of one pruned marker. For e.g:if following is the successors set of a cset A: A -> [a, b, c] if we prune c, we expect A's successors set to be [a, b] but you would get: A -> [] So this patch make sure that we calculate the right successorsset of csets considering the pruned cset (in split case). Differential Revision: https://phab.mercurial-scm.org/D5474
Sun, 06 Jan 2019 09:34:41 +0530 histedit: add user input to warning message on editing tagged commits
Navaneeth Suresh <navaneeths1998@gmail.com> [Sun, 06 Jan 2019 09:34:41 +0530] rev 41151
histedit: add user input to warning message on editing tagged commits This is a follow-up patch to D5489. Now, the user will be able to input yes/no(default) on the warning message. Initially, it was the sleep of 1s and histedit window opens. Changes were made as suggested by @mharbison72 and @yuja. Differential Revision: https://phab.mercurial-scm.org/D5494
Mon, 24 Dec 2018 16:04:52 +0300 sparse: fix debugrebuilddirsate when narrow extension is enabled
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 24 Dec 2018 16:04:52 +0300] rev 41150
sparse: fix debugrebuilddirsate when narrow extension is enabled dirstate wrapping in narrow extension converts the manifest object to a list. So let's assume we get a list of files in sparse extension. Differential Revision: https://phab.mercurial-scm.org/D5481
Mon, 24 Dec 2018 15:57:54 +0300 tests: show that debugrebuilddirstate is broken with narrow+sparse
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 24 Dec 2018 15:57:54 +0300] rev 41149
tests: show that debugrebuilddirstate is broken with narrow+sparse This adds a test to show that debugrebuildirstate is broken when both narrow and sparse extensions are enabled. Differential Revision: https://phab.mercurial-scm.org/D5480
Mon, 24 Dec 2018 15:30:39 +0300 sparse: don't enable on clone if it was a narrow clone
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 24 Dec 2018 15:30:39 +0300] rev 41148
sparse: don't enable on clone if it was a narrow clone When both sparse and narrow extensions are enabled and we do a narrow clone, sparse enables itself because it reads --include flag and thinks that user is trying to do a sparse clone. This patch changes that behavior, and now if both extensions are enabled and user passes `--narrow`, then the includes and excludes won't be considered as part of sparse profile. Differential Revision: https://phab.mercurial-scm.org/D5479
Mon, 24 Dec 2018 15:01:47 +0300 tests: add tests for narrow clone when both sparse and narrow are enabled
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 24 Dec 2018 15:01:47 +0300] rev 41147
tests: add tests for narrow clone when both sparse and narrow are enabled This patch adds tests for doing a narrow clone when client has both sparse and narrow enabled. As shown by this patch, we can see that the narrow clone has sparse enabled which we does not want here. Upcoming patch will fix this. Also while writing tests, I realized we don't have a flag to list the current sparse profile. Differential Revision: https://phab.mercurial-scm.org/D5478
Wed, 09 Jan 2019 20:00:35 -0800 histedit: crashing with a more useful error message on empty defaultrev stable
rdamazio@google.com [Wed, 09 Jan 2019 20:00:35 -0800] rev 41146
histedit: crashing with a more useful error message on empty defaultrev Before this, `hg --config histedit.defaultrev= histedit` would crash with File "destutil.py", line 385, in desthistedit if revs: UnboundLocalError: local variable 'revs' referenced before assignment Differential Revision: https://phab.mercurial-scm.org/D5543
Tue, 08 Jan 2019 00:30:30 -0800 progress: check what type of progress bar to use only once per topic
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:30:30 -0800] rev 41145
progress: check what type of progress bar to use only once per topic This seems to have sped up `hg perfprogress` from 1.78 s to 1.41 s. Differential Revision: https://phab.mercurial-scm.org/D5530
Tue, 08 Jan 2019 00:17:41 -0800 progress: split up _print() method in bar-updating and debug-printing
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:17:41 -0800] rev 41144
progress: split up _print() method in bar-updating and debug-printing I just thought this was clearer, but it turned out to also simplify the next patch. This seems to have sped up `hg perfprogress` from 1.85 s to 1.78 s. Differential Revision: https://phab.mercurial-scm.org/D5529
Tue, 08 Jan 2019 00:12:08 -0800 progress: move cached debug flag from progress.progbar to scmutil.progress
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:12:08 -0800] rev 41143
progress: move cached debug flag from progress.progbar to scmutil.progress It's simpler this way. One possible drawback (and a possisble advantage) is that we now check the debug flag once per topic, so processes that generate new topics all the time will still check the flag frequently. Differential Revision: https://phab.mercurial-scm.org/D5528
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip