Siddharth Agarwal <sid0@fb.com> [Tue, 17 Mar 2015 13:41:24 -0700] rev 24417
patch.diff: add support for diffs relative to a subdirectory
For now this implementation is pretty naive -- it filters out files right
before passing them into trydiff. In upcoming patches we'll add some more
smarts.
Siddharth Agarwal <sid0@fb.com> [Tue, 17 Mar 2015 12:59:41 -0700] rev 24416
patch.trydiff: add support for stripping a relative root
This assumes that if relroot is not None, all the files in modified, added and
removed start with it. In upcoming patches we'll follow that.
Matt Mackall <mpm@selenic.com> [Fri, 20 Mar 2015 17:30:38 -0500] rev 24415
merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 20 Mar 2015 16:39:07 -0500] rev 24414
obsolete: mark warning for translation
No good reason not to.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 18 Mar 2015 23:03:41 -0400] rev 24413
subrepo: add basic support to hgsubrepo for the files command
Paths into the subrepo are not yet supported.
The need to use the workingctx in the subrepo will likely be used more in the
future, with the proposed working directory revset symbol. It is also needed
with archive, if that code is to be reused to support 'extdiff -S'.
Unfortunately, it doesn't seem possible to put the smarts in subrepo.subrepo(),
as it breaks various status and diff tests.
I opted not to pass the desired revision into the subrepo method explicitly,
because the only ones that do pass an explicit revision are methods like status
and diff, which actually operate on two contexts- the subrepo state and the
explicitly passed revision.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 20 Mar 2015 00:30:35 -0700] rev 24412
mergecopies: reuse ancestry context when traversing file history (issue4537)
Merge copies is traversing file history in search for copies and renames.
Since 3.3 we are doing "linkrev adjustment" to ensure duplicated filelog entry
does not confuse the traversal. This "linkrev adjustment" involved ancestry
testing and walking in the changeset graph. If we do such walk in the changesets
graph for each file, we end up with a 'O(<changesets>x<files>)' complexity
that create massive issue. For examples, grafting a changeset in Mozilla's repo
moved from 6 seconds to more than 3 minutes.
There is a mechanism to reuse such ancestors computation between all files. But
it has to be manually set up in situation were it make sense to take such
shortcut. This changesets set this mechanism up and bring back the graph time
from 3 minutes to 8 seconds.
To do so, we need a bigger control on the way 'filectx' are instantiated during
each 'checkcopies' calls that 'mergecopies' is doing. We add a new 'setupctx'
that configure and return a 'filectx' factory. The function make sure the
ancestry context is properly created and the factory make sure it is properly
installed on returned 'filectx'.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 19 Mar 2015 23:57:34 -0700] rev 24411
adjustlinkrev: handle 'None' value as source
When the source rev value is 'None', the ctx is a working context. We
cannot compute the ancestors from there so we directly skip to its
parents. This will be necessary to allow 'None' value for
'_descendantrev' itself necessary to make all contexts used in
'mergecopies' reuse the same '_ancestrycontext'.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 19 Mar 2015 23:52:26 -0700] rev 24410
adjustlinkrev: prepare source revs for ancestry only once
We'll need some more complex initialisation to handle workingfilectx
case. We do this small change in a different patch for clarity.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 18 Mar 2015 22:56:41 -0400] rev 24409
subrepo: add the parent context to hgsubrepo
This brings parity with gitsubrepo and svnsubrepo (which already reference their
parent), and will be used in an upcoming patch.
I'm a bit concerned that the parent context could get stale (consider what
happens when the parent repo is reverted for example). I tried adding the
parent context to the substate tuple so that the parent is available everywhere
a state change is possible, but that made submerge() unhappy. Even with
removing the parent context inside submerge(), I wasn't able to get all of the
test diffs fixed.
But since the other subrepos reference their parent too, if there is a problem,
it is a preexisting one (that nobody seems to be running into). It can be fixed
if/when it pops up.
Siddharth Agarwal <sid0@fb.com> [Thu, 19 Mar 2015 21:26:18 -0700] rev 24408
fileset: add a fileset for portable filenames
This has mostly the same semantics as the files that the 'ui.portablefilenames'
config option would warn or abort about. The only difference is filenames that
case-fold to the same string -- given a set of filenames we've already
checked we can check whether a new one collides with them, but we don't have a
way to tell which filename it collided with.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 19 Mar 2015 19:52:23 -0700] rev 24407
annotate: reuse ancestry context when adjusting linkrev (issue4532)
The linkrev adjustment will likely do the same ancestry walking multiple time
so we already have an optional mechanism to take advantage of this. Since
2896f53509a7, linkrev adjustment was done lazily to prevent too bad performance
impact on rename computation. However, this laziness created a quadratic
situation in 'annotate'.
Mercurial repo: hg annotate mercurial/commands.py
before: 8.090
after: 36.300
Mozilla repo: hg annotate layout/generic/nsTextFrame.cpp
before: 1.190
after: 290.230
So we setup sharing of the ancestry context in the annotate case too. Linkrev
adjustment still have an impact but it a much more sensible one.
Mercurial repo: hg annotate mercurial/commands.py
before: 36.300
after: 10.230
Mozilla repo: hg annotate layout/generic/nsTextFrame.cpp
before: 290.230
after: 5.560
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Mar 2015 16:01:16 -0700] rev 24406
treemanifest: make hasdir() faster
Same rationale as the previous change.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Mar 2015 13:50:06 -0800] rev 24405
treemanifest: make filesnotin() faster
Same rationale as the previous change.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Feb 2015 17:13:35 -0800] rev 24404
treemanifest: make diff() faster
Containment checking is slower in treemanifest than it is in
manifestdict, making the current diff algorithm O(n log n). By
traversing both treemanifests in parallel, we can make it O(n). More
importantly, once we start lazily loading submanifests, we will be
able to easily skip entire submanifest if they have the same nodeid.