timeless <timeless@mozdev.org> [Thu, 04 Feb 2016 03:47:38 +0000] rev 28124
shelve: suggest the correct tool to continue (not unshelve)
Suggest committing (or whatever the current activity is), via
wrongtooltocontinue which uses howtocontinue.
timeless <timeless@mozdev.org> [Thu, 04 Feb 2016 03:47:00 +0000] rev 28123
histedit: suggest the correct tool to continue (not histedit)
Suggest committing (or whatever the current activity is), via
wrongtooltocontinue which uses howtocontinue.
timeless <timeless@mozdev.org> [Thu, 04 Feb 2016 03:46:38 +0000] rev 28122
rebase: suggest the correct tool to continue (not rebase)
Suggest committing (or whatever the current activity is), via
wrongtooltocontinue which uses howtocontinue.
timeless <timeless@mozdev.org> [Thu, 04 Feb 2016 03:45:44 +0000] rev 28121
graft: suggest the correct tool to continue (not graft)
Add test coverage for graft --continue without starting.
Suggest committing (or whatever the current activity is), via
wrongtooltocontinue which uses howtocontinue.
timeless <timeless@mozdev.org> [Sun, 14 Feb 2016 16:16:17 +0000] rev 28120
cmdutil: provide a way to report how to continue
checkafterresolved allows Mercurial to suggest what command to
use next. If users try to continue the wrong command, there
wasn't a good way for the command to suggest what to do next.
Split checkmdutil into howtocontinue and checkafterresolved.
Introduce wrongtooltocontinue which handles raising an Abort with
the hint from howtocontinue.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 14 Feb 2016 01:33:55 +0900] rev 28119
hg: make cachedlocalrepo cache appropriate repoview object
Before this patch, 'cachedlocalrepo' always caches "visible" repoview
object, because 'cachedlocalrepo' uses "visible" repoview returned by
'hg.repository()' without any additional processing.
If the client of 'cachedlocalrepo' wants "served" repoview, some
objects to be cached are discarded unintentionally.
1. 'cachedlocalrepo' newly caches "visible" repoview object
(call it VIEW1)
2. 'cachedlocalrepo' returns VIEW1 to the client of it at 'fetch()'
3. the client gets "served" repoview object by 'filtered("served")'
on VIEW1 (call this "served" repoview VIEW2)
4. accessing to 'repo.changelog' implies:
- instantiation of changelog via 'localrepository.changelog'
- instantiation of "filtered changelog" via 'repoview.changelog'
5. "filtered changelog" above is cached in VIEW2
6. VIEW2 is discarded after processing, because there is no
reference to it
7. 'cachedlocalrepo' returns VIEW1 cached at (1) above to the
client at next 'fetch()'
8. 'filtered("served")' on VIEW1 at the client side creates new
"served" repoview again, because VIEW1 is "visible"
(call this new "served" repoview VIEW3)
9. accessing to 'repo.changelog' implies instantiation of filtered
changelog again, because "filtered changelog" is cached in
VIEW2 at (5), but not in VIEW3 currently used
10. (go to (7) above)
As described above, "served" repoview object and "filtered changelog"
cached in it are discarded always, even if the repository itself
hasn't been changed since last access.
For example, in the case of 'hgweb_mod.hgweb', "newly caching" occurs,
when:
- all cached objects are already assigned to another threads
(in this case, repoview is created in 'cachedlocalrepo.copy()')
- or, stat of '00changelog.i' is changed from last access
(in this case, repoview is created in 'cachedlocalrepo.fetch()')
once changes are pushed via HTTP, this always occurs.
The root cause of this inefficiency is that 'cachedlocalrepo' always
caches "visible" repoview object, even if the client of it wants
another view.
To make 'cachedlocalrepo' cache appropriate repoview object, this
patch adds additional filtering on the repo object returned by
'hg.repository()'. It is assumed that initial repoview object should
be already filtered by expected view.
After this patch:
- 'filtered("served")' on VIEW1 at (3)/(7) above returns VIEW1
itself, because VIEW1 is now "served", and
- VIEW2 and VIEW3 equal VIEW1
- therefore, "filtered changelog" is cached in VIEW1, and reused
intentionally
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 14 Feb 2016 00:45:17 +0000] rev 28118
rebase: perform update through the 'update' command
The update logic have grow more and more complicated over time (eg bookmark
movement, new destination logic, warning on other head, etc). The rebase
extension was reimplementing its own basic version of update to be used by 'hg
pull --rebase'. We remove the custom code and use a combination of higher level
functions.
A test is added to check that the update is properly warning about other branch
heads.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 13 Feb 2016 16:59:32 +0000] rev 28117
rebase: 'hg pull --rebase' now update only if there was nothing to rebase
I recently discovered that 'hg pull --rebase' was also running an update. And it
was running it in all cases as long as the update would move the working copy
somewhere else...
This felt wrong and it actually is. This 'update' call is introduced in
92455c1d6f83. In that commit the intent is very clear. The update should happen
only when there was nothing to rebase. The implementation did not check if a
rebase was performed because, at that time, rebase would always leave you on the
top most changeset. Being on that top most changeset result in a no-op update
and the step was skipped.
However 9c78ed396075f changed rebase behavior to preserve the working copy
parent, so if we are not on a head at pull time, the code performs both a rebase
and an update.
This changeset introduce a test for this case and restore the intended behavior.
There are other issues with this custom update code but they will be addressed
in later changeset (eg: own destination logic, lack of heads warning).
I'm not super happy with the explicitly comparison 'rebase(...) == 1' but a
later series will have a cleaner way to handle it anyway (while making 'rebase'
pick its default destination like 'merge').
Durham Goode <durham@fb.com> [Mon, 08 Feb 2016 14:17:11 -0800] rev 28116
filectx: replace use of _filerev with _filenode
_filerev depends on the filelog implementation using revlogs and linkrevs.
Alternative implementations, like remotefilelog, do not have rev numbers, so
this call fails. Replacing it with _filenode means it doesn't rely on rev
numbers, and doesn't cost anything extra, since _filerev is using _filenode
under the hood anyway.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Feb 2016 15:53:48 -0800] rev 28115
verify: extract "manifest" constant into variable
The "manifest" label that's used in error messages will instead be the
directory path for subdirectory manifests (not the root manifest), so
let's extract the constant to a variable already to make future
patches simpler.