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.
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.
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.
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.
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
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
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.
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:30:30 -0800] rev 41146
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
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:17:41 -0800] rev 41145
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
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 00:12:08 -0800] rev 41144
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 Jan 2019 23:55:26 -0800] rev 41143
progress: write ui.progress() in terms of ui.makeprogress()
I think ui.makeprogress() should be the preferred interface and we
should deprecate ui.progress(). All in-core callers already use
ui.makeprogress(). Moving the logic to the scmutil.progress() will let
us make further improvements.
This seems to have sped up `hg perfprogress` from 1.92 s to 1.85 s,
perhaps because we now skip the indirection of updating the progress
bar via ui.progress().
Differential Revision: https://phab.mercurial-scm.org/D5527