timeless <timeless@mozdev.org> [Mon, 08 Feb 2016 05:56:25 +0000] rev 28145
tests: change branches test to work cross platform
While it is not easy to make a file 000 on Windows, you can
emulate most of the behaviors by replacing the file with a directory.
Kostia Balytskyi <ikostia@fb.com> [Mon, 15 Feb 2016 10:48:36 +0000] rev 28144
histedit: change string literals to constants in goal naming
This is a part of bigger effort to refactor histedit with ultimate
goal of understanding it.
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Feb 2016 18:08:59 +0900] rev 28143
run-tests: add --chg option to install and run tests using chg
Because the temporary installation directory is shared between hg and chg,
--chg is not allowed if --with-hg option is specified. Also, --chg option
does not work on FreeBSD because "make" command is hard-coded. These
limitations can be improved later.
Almost all tests will fail with chg right now.
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Feb 2016 16:34:12 +0900] rev 28142
run-tests: add --with-chg option to run tests using chg
Unlike --with-hg=/path/to/chg, this option allows us to start and clean up
command servers in isolated environment. And we can specify the hg command
as well as the chg command.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Feb 2016 23:30:41 +0000] rev 28141
destutil: add more precise error classes for destmerge
Having exception classes more precise than 'Abort' will allow us to properly
catch "nothing to rebase" situations when we will be using 'destmerge' in
rebase.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 22:58:15 +0000] rev 28140
destutil: allow to disable the "on head check" in destmerge
'hg merge' refuses to pick a default destination if the working copy is not on
a head. This is a very sensible default for 'hg merge' but 'hg rebase' should
work in this situation. So we introduce a way to disable this check. It will
soon be used by rebase.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 19:32:29 +0100] rev 28139
destutil: allow to specify an explicit source for the merge
We can now specify from where the merge is performed. The experimental revset
is updated to take revisions as argument, allowing to test the feature.
This will become very useful for pick the 'rebase' default destination. For this
reason, we also exclude all descendants from the rebased set from the candidate
destinations. This descendants exclusion was not necessary for merge as default
destination would not be picked from anything else than a head.
I'm not super excited with the current error messages, but I would prefer to
delay an overall messages rework once 'hg rebase' is done getting a default
destination aligned with 'hg merge'.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 18:12:06 +0100] rev 28138
destutil: remove current head from list of candidates early
While 'hg merge' will refuse to pick a default destination if the working copy
is not on a head, this will be a common and valid case for rebase. In this
case, we will need to exclude from the candidate destination all descendants
from the rebased set.
We make a step forward in that direction by removing parents of the working
copy from the candidate destinations instead of manually filtering the working
copy parent at the end of the process. This will make the extra step of
filtering descendant much simpler in a future changeset.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 17:53:44 +0100] rev 28137
destutil: add an 'action' layer to the destmerge message dictionary
We'll introduce messages for 'rebase' soon, so we introduce a way to select
a message based on the action being performed.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Feb 2016 23:49:55 +0000] rev 28136
rebase: extract rebaseset and destination computation in a function
The whole rebase function is gargantuan and this computation is almost 100 lines
long. We extract it in a dedicated function as it is independent from the rest
of the rebase code.
Having it in its own function will make it easier to rework the default
destination logic.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Feb 2016 22:47:20 +0000] rev 28135
tests: have a more elaborated test for _destrebase
The previous repo had a single lineage and a single head, pretty boring for
rebase related testing.
Kostia Balytskyi <ikostia@fb.com> [Sun, 14 Feb 2016 21:15:59 +0000] rev 28134
histedit: break _histedit function into smaller pieces
We add _getgoal, _validateargs.
This is a part of bigger effort to refactor histedit. Initial steps are to
break _histedit function into smaller pieces which will supposedly be more
understandable. After this is done, I will have a better understanding
of how histedit works and apply that to fix
issue4800.
Kostia Balytskyi <ikostia@fb.com> [Sun, 14 Feb 2016 21:00:05 +0000] rev 28133
histedit: break _histedit function into smaller pieces (add _continueaction)
This is a part of bigger effort to refactor histedit. Initial steps are to
break _histedit function into smaller pieces which will supposedly be more
understandable. After this is done, I will have a better understanding
of how histedit works and apply that to fix
issue4800.
Kostia Balytskyi <ikostia@fb.com> [Mon, 01 Feb 2016 17:20:51 +0000] rev 28132
histedit: break _histedit function into smaller pieces (add _newaction)
This is a part of bigger effort to refactor histedit. Initial steps are to
break _histedit function into smaller pieces which will supposedly be more
understandable. After this is done, I will have a better understanding
of how histedit works and apply that to fix
issue4800.
Kostia Balytskyi <ikostia@fb.com> [Mon, 01 Feb 2016 14:12:38 +0000] rev 28131
histedit: break _histedit function into smaller pieces (add _editplanaction)
This is a part of bigger effort to refactor histedit. Initial steps are to
break _histedit function into smaller pieces which will supposedly be more
understandable. After this is done, I will have a better understanding
of how histedit works and apply that to fix
issue4800.
Kostia Balytskyi <ikostia@fb.com> [Mon, 01 Feb 2016 12:51:20 +0000] rev 28130
histedit: break _histedit function into smaller pieces (add _abortaction)
This is a part of bigger effort to refactor histedit. Initial steps are to
break _histedit function into smaller pieces which will supposedly be more
understandable. After this is done, I will have a better understanding
of how histedit works and apply that to fix
issue4800.
Martijn Pieters <mjpieters@fb.com> [Mon, 08 Feb 2016 13:52:51 +0000] rev 28129
automv: new experimental extension
Automatically detect moves and record them at commit time.
This extension was originally developed at
https://bitbucket.org/facebook/hg-experimental
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Feb 2016 21:25:44 -0800] rev 28128
match: override 'visitdir' in subdirmatcher
The manifest.manifest class has a _treeinmem member than one can
manually set to True to test that the treemanifest class works as a
drop-in replacement for manifestdict (which is mostly a requirement
for treemanifest repos to work). However, it doesn't quite work at the
moment. These tests fail:
test-largefiles-misc.t
test-rebase-newancestor.t
test-subrepo.t
test-subrepo-deep-nested-change.t
test-subrepo-recursion.t
All but test-rebase-newancestor.t fail because they trigger calls to
subdirmatcher.visitdir(), which tries to access a _excluderoots field
that does not exist on the subdirmatcher. Let's fix that by overriding
visitdir() in a similar way to how matchfn is overridden, i.e. by
prepending the directory before calling the superclass method.
Yuya Nishihara <yuya@tcha.org> [Sat, 09 Jan 2016 13:22:26 +0900] rev 28127
run-tests: remove useless "failed" flag from addOutputMismatch()
It never be set to True.
Yuya Nishihara <yuya@tcha.org> [Sat, 09 Jan 2016 13:20:15 +0900] rev 28126
tests: load json with no fallback
The json module should be available in Python 2.6 or newer.
Yuya Nishihara <yuya@tcha.org> [Tue, 15 Dec 2015 23:50:48 +0900] rev 28125
config: drop progress extension from sample hgrc as it is in core now
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.