Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Apr 2019 14:11:54 -0700] rev 42224
copies: replace .items() by .values() where appropriate
As pointed out by Pierre-Yves.
Differential Revision: https://phab.mercurial-scm.org/D6266
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Apr 2019 10:44:37 -0700] rev 42223
copies: inline _computenonoverlap() in mergecopies()
We now call pathcopies() from the base to each of the commits, and
that calls _computeforwardmissing(), which does file prefetching (in
the remotefilelog override). So the call to _computenonoverlap() is
now pointless (the sets of files from _computenonoverlap() are subsets
of the sets of files from _computeforwardmissing()).
This somehow also fixes a broken remotefilelog test.
Differential Revision: https://phab.mercurial-scm.org/D6256
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Apr 2019 23:22:54 -0700] rev 42222
copies: calculate mergecopies() based on pathcopies()
When copies are stored in changesets, we need a changeset-centric
version of mergecopies() just like we have a changeset-centric version
of pathcopies(). I think the natural way of thinking about
mergecopies() is in terms of pathcopies() from the base to each of the
commits. So if we can rewrite mergecopies() based on two such
pathcopies() calls, we'll get the changeset-centric version for
free. That's what this patch does.
A nice bonus is that it ends up being a lot simpler. mergecopies() has
accumulated a lot of technical debt over time. One good example is the
code for dealing with grafts (the "partial/incomplete/dirty"
stuff). Since pathcopies() already deals with backwards renames and
ping-pong renames, we get that for free.
I've run tests with hard-coded debug logging for "fullcopy" and while
I haven't looked at every difference it produces, all the ones I have
looked at seemed reasonable to me. I'm a little surprised that no more
tests fail when run with '--extra-config-opt
experimental.copies.read-from=compatibility' compared to before this
patch. This patch also fixes the broken cases in test-annotate.t and
test-fastannotate.t. It also enables the part of test-copies.t that
was previously disabled exactly because mergecopies() needed to get a
changeset-centric version.
One drawback of the rewritten code is that we may now make
remotefilelog prefetch more files. We used to prefetch files that were
unique to either side of the merge compared to the other. We now
prefetch files that are unique to either side of the merge compared to
the base. This means that if you added the same file to each side, we
would not prefetch it before, but we would now. Such cases are
probably quite rare, but one likely scenario where they happen is when
moving from a commit to its successor (or the other way around). The
user will probably already have the files in the cache in such cases,
so it's probably not a big deal.
Some timings for calculating mergecopies between two revisions
(revisions shown on each line, all using the common ancestor as base):
In the hg repo:
4.8 4.9: 0.21s -> 0.21s
4.0 4.8: 0.35s -> 0.63s
In and old copy of the mozilla-unified repo:
FIREFOX_BETA_60_BASE^ FIREFOX_BETA_60_BASE: 0.82s -> 0.82s
FIREFOX_NIGHTLY_59_END FIREFOX_BETA_60_BASE: 2.5s -> 2.6s
FIREFOX_BETA_59_END FIREFOX_BETA_60_BASE: 3.9s -> 4.1s
FIREFOX_AURORA_50_BASE FIREFOX_BETA_60_BASE: 31s -> 33s
So it's measurably slower in most cases. The most significant
difference is in the hg repo between revisions 4.0 and 4.8. In that
case it seems to come from the fact that pathcopies() uses
fctx.isintroducedafter() (in _tracefile), while the old mergecopies()
used fctx.linkrev() (in _checkcopies()). That results in a single call
to filectx._adjustlinkrev(), which is responsible for the entire
difference in time (in my repo). So we pay a performance penalty but
we get more correct code (see change in
test-mv-cp-st-diff.t). Deleting the "== f.filenode()" in _tracefile()
recovers the lost performance in the hg repo.
There were are few other optimizations in _checkcopies() that I could
not measure any impact from. One was from the "seen" set. Another was
from a "continue" when the file was not in the destination manifest
(corresponding to "am" in _tracefile).
Also note that merge copies are not calculated when updating with a
clean working copy, which is probably the most common case. I
therefore think the much simpler code is worth the slowdown.
Differential Revision: https://phab.mercurial-scm.org/D6255
Martin von Zweigbergk <martinvonz@google.com> [Mon, 29 Apr 2019 14:38:54 -0700] rev 42221
tests: add test where copy source is deleted and added back
This shows another difference between pathcopies() and mergecopies():
mergecopies() considers files that have been deleted and then added
back as different files, but pathcopies() does not.
Differential Revision: https://phab.mercurial-scm.org/D6330
Augie Fackler <augie@google.com> [Wed, 01 May 2019 14:30:25 -0400] rev 42220
merge with stable
Augie Fackler <raf@durin42.com> [Wed, 01 May 2019 14:27:19 -0400] rev 42219
Added signature for changeset
07e479ef7c96
Augie Fackler <raf@durin42.com> [Wed, 01 May 2019 14:27:17 -0400] rev 42218
Added tag 5.0 for changeset
07e479ef7c96
Matt Harbison <matt_harbison@yahoo.com> [Mon, 29 Apr 2019 23:00:42 -0400] rev 42217
obsolete: drop the legacy `_enabled` variable
Evolve 8.5.0 stopped setting this, and it would have been easier to figure out
why TortoiseHg stopped allowing amends if it would have crashed on the missing
variable.
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 27 Apr 2019 14:43:43 +0300] rev 42216
discovery: only calculate closed branches if required
The number of new closed branches is required for printing in error message. So
let's only calculate them if we need to print error about new branches.
Differential Revision: https://phab.mercurial-scm.org/D6314
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Apr 2019 19:17:02 +0200] rev 42215
hghave: deal with "rc" release
Without this change, 5.0rc0 is not recognised as 5.0
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 27 Apr 2019 02:13:43 +0300] rev 42214
branchcache: store the maximum tip in a variable inside for loop
Instead of assigning self.tiprev multiple times in the for loop, and calling
cl.node() on it, let's store that in a temporary variable and assign it in the
end of loop.
Differential Revision: https://phab.mercurial-scm.org/D6311
Martin von Zweigbergk <martinvonz@google.com> [Sat, 27 Apr 2019 23:30:19 -0700] rev 42213
tests: demonstrate that rename is followed to wrong parent from merge
This test case shows another way that copies are handled differently
between `hg st` (pathcopies()) and `hg co -m` (mergecopies). The
reason is that pathcopies() calls _tracefiles(), which checks that the
file nodeid of an ancestor matches the file nodeid in the base
commit. mergecopies() should probably be doing the same.
Differential Revision: https://phab.mercurial-scm.org/D6323
Martin von Zweigbergk <martinvonz@google.com> [Sat, 27 Apr 2019 23:14:49 -0700] rev 42212
test: demonstrate failure to follow rename with shadowed linkrev
This shows a difference in handling of copies between `hg st`
(pathcopies()) and `hg co -m`. The issue here is that mergecopies()
uses the unadjusted linkrev() for determining when to stop walking
ancestors.
Differential Revision: https://phab.mercurial-scm.org/D6322
Martin von Zweigbergk <martinvonz@google.com> [Sat, 27 Apr 2019 22:57:15 -0700] rev 42211
tests: slightly modify a linkrev test to prepare for expanding it
The test case checks that the copy tracing code doesn't get confused
by linkrevs when walking a file's ancestors. This patch chnages the
test slightly so a second commit is grafted, thus producing a second
"bad" linkrev. I'll use this in the next patch to demonstrate a bug.
Differential Revision: https://phab.mercurial-scm.org/D6321
Martin von Zweigbergk <martinvonz@google.com> [Sat, 27 Apr 2019 22:55:54 -0700] rev 42210
copies: process files in deterministic order for stable tests
I also fixed a typo while at it.
Differential Revision: https://phab.mercurial-scm.org/D6320
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 17 Apr 2019 15:06:41 +0300] rev 42209
narrow: send specs as bundle2 data instead of param (
issue5952) (
issue6019)
Before this patch, when ACL is involved, narrowspecs are send as bundle2
parameter for narrow:spec bundle2 part. The limitation of bundle2 parts are they
cannot send data larger than 255 bytes. Includes and excludes in narrow are not
limited by size and they can grow over 255 bytes.
This patch introduces a new mandatory bundle2 part and send narrowspecs as data
of that. The new bundle2 part is introduced to keep things cleaner and easy to
distinguish related to backward compatibility.
The part is mandatory because without server's narrowspec, the local ACL narrow
repo won't work.
This patch makes clients compatible with servers which have older versions.
However I left a comment that we should drop the other bundle2 part soon as
that's broken and people should not rely on that.
I named the new bundle2 part 'Narrow:responsespec' because:
1) Capital 'N' to make it mandatory
2) 'Narrow:spec' cannot be used because bundle2 enforces that there should not
be two different parts which resolve to same name when lowercased.
3) reponsespec clears that they are specs which are send as reponse by the
server
While I was here, I renamed `narrowhgacl` section to `narrowacl` as suggested by
idlsoft@ and martinvonz@.
Differential Revision: https://phab.mercurial-scm.org/D6310
Ludovic Chabant <ludovic@chabant.com> [Fri, 19 Apr 2019 14:26:32 +0000] rev 42208
py3: properly reject non-encoded strings given to hgweb
Ludovic Chabant <ludovic@chabant.com> [Fri, 19 Apr 2019 14:25:18 +0000] rev 42207
py3: handle meta-path finders that only use pre-python3.4 API
Danny Hooper <hooper@google.com> [Fri, 26 Apr 2019 17:41:22 -0700] rev 42206
remotefilelog: add missing argument to hg.verify wrapper
Differential Revision: https://phab.mercurial-scm.org/D6313
Boris Feld <boris.feld@octobus.net> [Thu, 24 Jan 2019 09:03:15 -0500] rev 42205
revsetbenchmark: track some simple use of "only"
The only revset is quite useful and has various possible optimisation. tracking
its timing seems useful.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 26 Apr 2019 23:52:49 -0400] rev 42204
inno: bump keyring to 18.0.1 to avoid AttributeError (
issue6043)
The error seems to be harmless, because it happens after closing the connection.
For whatever reason, this isn't bundled with the Wix installer.
https://github.com/jaraco/keyring/issues/386
https://bitbucket.org/Mekk/mercurial_keyring/issues/63/attributeerror-during-process-finish-with
Taapas Agrawal <taapas2897@gmail.com> [Fri, 01 Mar 2019 05:56:18 +0530] rev 42203
push: added clear warning message when pushing closed branches(
issue6080)
Differential Revision: https://phab.mercurial-scm.org/D6038
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:06:20 +0530] rev 42202
branch: abort if closing branch from a non-branchhead cset
This patch make sure that we abort if the user is trying to
close a branch from a cset which is not a branch head.
Changes in test file reflect the fixed behaviour.
Differential Revision: https://phab.mercurial-scm.org/D6282
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 01:19:58 +0530] rev 42201
branch: add tests which shows branch can be closed from a non-branchhead cset
This patch shows that we can close a branch even from a cset which is not
a branch head. It was supposed to abort this operation.
Next patch will be fixing the issue.
Differential Revision: https://phab.mercurial-scm.org/D6281