Martin von Zweigbergk <martinvonz@google.com> [Sun, 31 Mar 2019 09:39:02 -0700] rev 42039
revset: remove comment about linkrev workaround from user-facing docs
I think the code is clear enough so we don't need to keep the comment
at all (by now, most Mercurial developers are probably familiar with
the linkrevs issues).
Differential Revision: https://phab.mercurial-scm.org/D6176
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Mar 2019 11:32:02 -0700] rev 42038
shelve: let cmdutil.revert() take care of backing up untracked files
cmdutil.revert() backs up untracked files, so I don't see a reason to
do it shelve.mergefiles(). We have tests for this and they still pass.
Differential Revision: https://phab.mercurial-scm.org/D6174
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Mar 2019 11:31:42 -0700] rev 42037
shelve: stop passing list of files to revert
It seems to work just fine to not specify any files here. I suspect it
looked the way it did for historical reasons. It apparently used to
use merge instead of rebase until
1d7a36ff2615 (shelve: use rebase
instead of merge (
issue4068), 2013-10-23) and it makes sense to want
to restrict the set of files then.
I noticed this because of the files.extend(shelvectx.p1().files()). If
the working copy was clean before, then shelvectx.p1() will be the
working copy parent and that ended up adding all the files in that
set. In our Google-internal Mercurial setup (including a FUSE) that
was very noticeably slow when the working copy parent happened to have
many files in large directories.
This patch doesn't yet remove the call to shelvectx.p1().files(). We
also use that set for deciding what to back up. I'm pretty sure it's
safe to back up only the set of files we already back even if we no
longer restrict the set of files to revert, so this patch should be
safe on its own. Regardless, the next patch will delegate the
backing-up to cmdutil.revert().
Incidentally, this also gets rid of a repo.pathto() that I had earlier
wanted to get rid of.
Differential Revision: https://phab.mercurial-scm.org/D6173
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Mar 2019 14:55:46 -0700] rev 42036
remotefilelog: prefetch files in deterministic order
I have been troubleshooting some slowness in this area (it's unclear
if it's the client or server that's to blame, but that's beside the
point) and it's a lot easier to do troubleshoot if the files are
prefetched in the same order each time.
Differential Revision: https://phab.mercurial-scm.org/D6172
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:35:28 +0100] rev 42035
debugdiscovery: display time elapsed during the discovery step
This is a useful information. Now that we perform more analysing after the
discovery is done, it is worth have a more precise measurement. For serious
timing analysis use `hg perfdiscovery`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:26:54 +0100] rev 42034
debugdiscovery: only list common heads on verbose
The list of common heads is only part of the useful information. In addition on
repository with many heads, the information is very not helpful (just fill a
couple of screen with hash). As a result we hide it behind a --verbose flag.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:26:11 +0100] rev 42033
debugdiscovery: drop duplicated information
The old line informing about the local being a superset or subset of the remote
is redundant with the newly introduced data. So we drop it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 17:25:22 +0100] rev 42032
debugdiscovery: display more statistic about the common set
We display a lot more information now. Especially, we display the overlap
between the common heads and the local/remote heads. There are various
optimization geared toward heads, as a result, the less common the heads the
more complex the discovery. Having this information easily accessible help when
working on discovery.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 14:04:33 +0100] rev 42031
debugdiscovery: small internal refactoring
The part of the code displaying statistic is made independant from the one
running the discovery. In the same do, the declaration of the discovery
function is a bit simplified.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 14:02:40 +0100] rev 42030
debugdiscovery: allow to select random seed during debugdiscovery run
The randomness can lead to large timing difference, controling it is important.
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:45:53 +0300] rev 42029
discovery: move cl.hasnode outside of the for-loop
IIUC, resolving attributes for changelog can lead to some overhead. So this
patch moves that to outside of a for-loop.
Differential Revision: https://phab.mercurial-scm.org/D6147
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:43:27 +0300] rev 42028
discovery: prevent deleting items from a dictionary
Removing elements from Python dictionary is expensive. So let's prevent adding
them instead.
I added a newline to make code look a bit better.
Differential Revision: https://phab.mercurial-scm.org/D6146
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:34:28 +0300] rev 42027
discovery: drop some unused sets
Differential Revision: https://phab.mercurial-scm.org/D6145
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:29:23 +0300] rev 42026
discovery: prevent recomputing info about server and outgoing changesets
We already iterate over the outgoing.missing above and lookup repo for them. So
let's reuse info calculated at that time instead of recomputing that again.
Also we calculate the set of remotebranches by doing set(remotemap), so let's
reuse that again.
Upcoming patches will clean things a bit more.
Differential Revision: https://phab.mercurial-scm.org/D6144