Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:58:01 -0400] rev 42495
shallowrepo: remove backwards compat code that predates in-tree remotefilelog
Differential Revision: https://phab.mercurial-scm.org/D6538
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:53:28 +0530] rev 42494
commit: make the error message more specific while aborting branch closing
Differential Revision: https://phab.mercurial-scm.org/D6493
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:33:54 +0530] rev 42493
commit: add a check if it is trying to close an already closed branch head
It would check if the revision we are going to close is already a
closed branch head and print the error message accordingly.
Differential Revision: https://phab.mercurial-scm.org/D6491
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:53:00 -0700] rev 42492
strip: move checksubstate() to mq (its only caller)
Differential Revision: https://phab.mercurial-scm.org/D6536
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:19:41 -0700] rev 42491
strip: use bailifchanged() instead of reimplementing it
This also means that we get the standard error messages (see changed
test cases).
Differential Revision: https://phab.mercurial-scm.org/D6535
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:40:24 -0700] rev 42490
strip: remove unused excsuffix argument from checklocalchanges()
It was only used by mq, and mq now has its own copy of the function.
Differential Revision: https://phab.mercurial-scm.org/D6534
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:38:50 -0700] rev 42489
mq: remove dependency on strip's checklocalchanges()
Some of the functionality in strip.checklocalchanges() was only used
by mq, so let's move it to mq so we can clean up strip.
Differential Revision: https://phab.mercurial-scm.org/D6533
Martin von Zweigbergk <martinvonz@google.com> [Thu, 02 May 2019 23:39:33 -0700] rev 42488
copies: avoid calling matcher if matcher.always()
When storing copy information in the changesets
(experimental.copies.read-from=changeset-only), this patch speeds up
hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2
from 5.9s to 4.7s. At the start of this series (
b162229e), that
command took 18min.
Differential Revision: https://phab.mercurial-scm.org/D6422
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:21:44 -0700] rev 42487
copies: avoid unnecessary copying of copy dict
When storing copy information in the changesets, this patch speeds up
hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2
from 11s to 5.9s. That command takes 6.2s when storing copy
information in filelogs.
Differential Revision: https://phab.mercurial-scm.org/D6421
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:22:14 -0700] rev 42486
copies: don't filter out copy targets created on other side of merge commit
If file X is copied to Y on one side of merge and the other side
creates Y (no copy), we would not mark that as copy. In the
changeset-centric pathcopies() version, that was done by checking if
the copy target existed on the other branch. Even though merge commits
are pretty uncommon, it still turned out to be too expensive to load
the manifest of the parents of merge commits. In a repo of
mozilla-unified converted to storing copies in changesets, about 2m30s
of `hg debugpathcopies FIREFOX_BETA_59_END FIREFOX_BETA_60_BASE` is
spent on this check of merge commits.
I tried to think of a way of storing more information in the
changesets in order to cheaply detect these cases, but I couldn't
think of a solution. So this patch simply removes those checks.
For reference, these extra copies are reported from the aforementioned
command after this patch:
browser/base/content/sanitize.js -> browser/modules/Sanitizer.jsm
testing/mozbase/mozprocess/tests/process_normal_finish_python.ini -> testing/mozbase/mozprocess/tests/process_normal_finish.ini
testing/mozbase/mozprocess/tests/process_waittimeout_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout.ini
testing/mozbase/mozprocess/tests/process_waittimeout_10s_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout_10s.ini
Since these copies were created on one side of some merge, it still
seems reasonable to include them, so I'm not even sure it's worse than
filelog pathcopies(), just different.
Differential Revision: https://phab.mercurial-scm.org/D6420
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 00:40:53 -0700] rev 42485
copies: do full filtering at end of _changesetforwardcopies()
As mentioned earlier, pathcopies() is very slow when copies are stored
in the changeset. Most of the cost comes from calling _chain() for
every changeset, which is slow because it needs to read manifests. It
needs to read manifests to be able to filter out copies that are were
created in one commit and then deleted. (It also filters out copies
that were created from a file that didn't exist in the starting
revision, but that's a fixed revision across calls to _chain(), so
it's much cheaper.)
This patch changes from _chainandfilter() to just _chain() in the main
loop in _changesetforwardcopies(). It instead removes copies that have
subsequently been removed by using ctx.filesremoved(). We thus rely on
that to be fast.
It timed this command in mozilla-unified:
hg debugpathcopies FIREFOX_59_0b3_BUILD2 FIREFOX_BETA_59_END
It took 18s before and 1.1s after. It's still faster when copy
information is stored in filelogs: 0.70s. It also still gets slow when
there are merge commits involved, because we read manifests there
too. We'll deal with that later.
Differential Revision: https://phab.mercurial-scm.org/D6419
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:58:53 +0900] rev 42484
rust-filepatterns: add comment about Windows path handling
As I replied to the Phabricator message, this is wrong. And I even suspect
it wouldn't compile because of multiple type mismatches.
I think, in Rust where type system is rock solid, we can live with UTF-8
strings except for the bottom storage layer and the top UI/command layer.
We'll still have to get around undecodable characters not to be lost, but
I think it's okay to drop such filenames from match result if they don't
match in UTF-8 world, not in Latin-1 world.