FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 08 Feb 2016 18:29:17 +0900] rev 28034
tests: make timezone in diff output glob-ed for portability
Before this patch, some tests using external "diff" command via
extdiff extension fail on Solaris, because system standard "diff" (=
/usr/bin/diff) on Solaris doesn't display timezone for timestamp of
each files in diff output.
This patch makes timezone in external diff output glob-ed for
portability of tests, and adds check-code.py a rule to detect such
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 08 Feb 2016 18:29:17 +0900] rev 28033
tests: omit -p for external diff via extdiff extension for portability
Before this patch, some tests using external "diff" command via
extdiff extension fail on Solaris, because "-p" (show which C function
each change is in) option isn't supported by system standard "diff" on
Solaris, even though extdiff passes it to external "diff" by default.
Fortunately, this non-portable option isn't important for (current, at
least) tests using external "diff" command via extdiff extension.
This patch omits "-p" for external "diff" command via extdiff
extension for portability of tests, and adds check-code.py a rule to
detect invocation of "diff" with "-p".
Newly added check-code.py rule examines only lines generated by
external "diff" with "-r", because strict examination might
misidentify "hg diff -p" or other complicated lines consisting of
"diff" string as wrong one.
This patch is a part of making tests using external "diff" portable,
and tests below aren't yet portable even after this patch.
test-graft.t
test-largefiles-update.t
test-subrepo-deep-nested-change.t
Martin von Zweigbergk <martinvonz@google.com> [Sun, 07 Feb 2016 22:18:24 -0800] rev 28032
update: check command line before modifying repo
A failed command should not have any effect on the repo.
Martin von Zweigbergk <martinvonz@google.com> [Sun, 07 Feb 2016 21:44:38 -0800] rev 28031
treemanifest: fix debugrebuildfncache
When I taught debugrebuildfncache about dirlogs in
fb92927f9775
(treemanifests: fix streaming clone, 2016-02-04), I added a
last-minute "if 'treemanifest' in repo" guard. That should have been
checking for "... in repo.requirements". Fix that and add tests for
it.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 03 Feb 2016 15:12:01 +0000] rev 28030
update: warn about other topological head in pull and unbundle
Other commands have a '--update' triggering a bare update. We now issue the
message introduced into the previous changeset for these too.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Feb 2016 14:49:02 +0000] rev 28029
update: warn about other topological heads on bare update
A concern around the user experience of Mercurial is user getting stuck on there
own topological branch forever. For example, someone pulling another topological
branch, missing that message in pull asking them to merge and getting stuck on
there own local branch.
The current way to "address" this concern was for bare 'hg update' to target the
tipmost (also latest pulled) changesets and complain when the update was not
linear. That way, failure to merge newly pulled changesets would result in some
kind of failure.
Yet the failure was quite obscure, not working in all cases (eg: commit right
after pull) and the behavior was very impractical in the common case
(eg:
issue4673).
To be able to change that behavior, we need to provide other ways to alert a
user stucks on one of many topological head. We do so with an extra message after
bare update:
1 other heads for branch "default"
Bookmark get its own special version:
1 other divergent bookmarks for "foobar"
There is significant room to improve the message itself, and we should augment
it with hint about how to see theses other heads or handle the situation (see
in-line comment). But having "a" message is already a significant improvement
compared to the existing situation. Once we have it we can iterate on a better
version of it. As having such message is an important step toward changing the
default destination for update and other nicety, I would like to move forward
quickly on getting such message.
This was discussed during London - October 2015 Sprint.
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 04:37:04 +0000] rev 28028
tests: mock getpid to reduce glob usage
With util.getpid, it is now possible to define fixed pids.
Future iterations can define a map of pids on a locked
first come first serve basis to create a more realistic
harness, but for now this is good enough.
This applies to blackbox, but could apply to other
tests as well.
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 09:11:22 +0000] rev 28027
util: enable getpid to be replaced
This will enable tests to write stable process ids.
timeless <timeless@mozdev.org> [Mon, 08 Feb 2016 00:47:36 +0000] rev 28026
blackbox: refactor use of vfs as _bbvfs
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 15:18:29 +0000] rev 28025
blackbox: flush output file descriptor
Without this, when there are multiple ui views, each blackbox
will have its own file handle, and the logging will be in
a really bad order.
Also, because of the way blackbox works, it never closes its
file handles, which means the last output before exit is
often lost.