Fri, 20 Mar 2015 17:30:38 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 20 Mar 2015 17:30:38 -0500] rev 24415
merge with stable
Fri, 20 Mar 2015 16:39:07 -0500 obsolete: mark warning for translation
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.
Wed, 18 Mar 2015 23:03:41 -0400 subrepo: add basic support to hgsubrepo for the files command
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.
Fri, 20 Mar 2015 00:30:35 -0700 mergecopies: reuse ancestry context when traversing file history (issue4537) stable
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'.
Thu, 19 Mar 2015 23:57:34 -0700 adjustlinkrev: handle 'None' value as source stable
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'.
Thu, 19 Mar 2015 23:52:26 -0700 adjustlinkrev: prepare source revs for ancestry only once stable
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.
Wed, 18 Mar 2015 22:56:41 -0400 subrepo: add the parent context to hgsubrepo
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip