Jun Wu <quark@fb.com> [Tue, 16 Feb 2016 11:08:52 +0000] rev 28196
chg: hold a lock file before connected to server
This is a part of the one server per config series. In multiple-server setup,
multiple clients may try to start different servers (on demand) at the same
time. The old lock will not guarantee a client to connect to the server it
just started, and is not crash friendly.
This patch addressed above issues by using flock and does not release the lock
until the client actually connects to the server or times out.
Jun Wu <quark@fb.com> [Mon, 22 Feb 2016 17:30:02 +0000] rev 28195
serve: allow --daemon-postexec to be 'unlink:path' or 'none'
This patch changes the format of value of --daemon-postexec. Now it can be
either to unlink a file, or a no-op. The following patch will make chg to
use the no-op option.
Jun Wu <quark@fb.com> [Mon, 22 Feb 2016 16:59:08 +0000] rev 28194
serve: rename --daemon-pipefds to --daemon-postexec (BC)
Initially we use --daemon-pipefds to pass file descriptors for synchronization.
Later, in order to support Windows, --daemon-pipefds is changed to accept a
file path to unlink instead. The name is outdated since then.
chg client is designed to use flock, which will be held before starting a
server and until the client actually connects to the server it started. The
unlink synchronization approach is not so helpful in this case.
To address the issues, this patch renames pipefds to postexec and the following
patch will allow the value of --daemon-postexec to be things like
'unlink:/path/to/file' or 'none'.
Tony Tung <tonytung@merly.org> [Mon, 22 Feb 2016 23:18:19 -0800] rev 28193
largefiles: don't explicitly list optional parameters that are not used
This makes it easier for changes to the API.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 23 Feb 2016 11:41:47 +0100] rev 28192
revert: properly revert to ancestor of p2 during merge (
issue5052)
During merge, added (from one perspective) file can be reported as "modified".
To work around that, revert was testing if modified file were present in the
parent manifest and marking them as "added" in this case. However, we should be
checking against the target revision manifest instead. Otherwise see file as
"newly added" even if they exist in the target revision.
That revert behavior regressed in
06fbd9518bc5.
Thomas Arendsen Hein <thomas@intevation.de> [Mon, 01 Feb 2016 12:36:28 +0100] rev 28191
help: hg.intevation.de is new primary name of hg.intevation.de (and new cert)
Adjust the examples (prefix and hostfingerprints) in help/config.txt
https://hg.intevation.de/ is now served with a new certificate that is signed
by a commercial CA, so all nearly all browsers will accept it automatically.
Listing both names, hg.intevation.de and hg.intevation.org, in the section
[hostfingerprints] allows using both without configuring web.cacerts and
without changing existing https URLs in the [paths] section.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 14:07:17 +0100] rev 28190
rebase: explicitly test abort from ambiguous destination
We want to explicitly test the next behavior. We add this test in its own
changeset to make the test change from the behavior change as clean as possible.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 14 Feb 2016 13:25:59 +0000] rev 28189
rebase: choose default destination the same way as 'hg merge' (BC)
This changeset finally make 'hg rebase' choose its default destination using the
same logic as 'hg merge'. The previous default was "tipmost changeset on the
current branch", the new default is "the other head if there is only one". This
change has multiple consequences:
- Multiple tests which were not rebasing anything (rebasing from tipmost head)
are now rebasing on the other "lower" branch. This is the expected new
behavior.
- A test is now explicitly aborting when there is too many heads on the branch.
This is the expected behavior.
- We gained a better detection of the "nothing to rebase" case while performing
'hg pull --rebase' so the message have been updated. Making clearer than an
update was performed and why. This is beneficial side-effect.
- Rebasing from an active bookmark will behave the same as 'hg merge' from a
bookmark.
Kostia Balytskyi <ikostia@fb.com> [Wed, 17 Feb 2016 20:31:34 +0000] rev 28188
rebase: add potential divergent commit hashes to error message (
issue5086)
Sune Foldager <sune.foldager@edlund.dk> [Fri, 19 Feb 2016 17:50:28 +0100] rev 28187
hgwebdir_wsgi: update script and expand help
I've updated the script to reflect changes in Mercurial and to include a much
more through installation guide with configuration examples and details on how
to configure IIS. I've used the script to set up a working server from scratch.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 22 Feb 2016 18:35:40 +0100] rev 28186
bundlerepo: properly handle hidden linkrev in filelog (
issue4945)
The bundlerepository have to do some special magic to handle linkrev of the
bundlerepo filerev. That logic was done from a repoview and obsolescence marker
affecting bundled changeset could lead to a crash. We now ensure we operate on
unfiltered repository.
liscju <piotr.listkiewicz@gmail.com> [Wed, 17 Feb 2016 22:45:01 +0100] rev 28185
rebase: adds storing collapse message (
issue4792)
Before this patch collapse message wasn't stored so when
you ran into the merge conflict while rebasing, running
rebase --continue didn't remember the message and
always opened editor to fill commit message.
This patch adds saving collapse message in
.hg/last-message.txt and restoring it later
when needed.
Augie Fackler <augie@google.com> [Mon, 22 Feb 2016 17:53:19 -0500] rev 28184
test-automv: fix inline config settings for
5ec1ce8fdf0a
Martijn Pieters <mjpieters@fb.com> [Tue, 16 Feb 2016 15:58:32 +0000] rev 28183
automv: use 95 as the default similarity threshold
The motivation for the change from 100 to 95 is included in a comment.
* Updated the tests to include a change to a moved file that still should be
caught as a move.
* Use ui.configint() to non-integer configuration entries more gracefully. Also
complain if a similarity outside of the acceptable range is set.
liscju <piotr.listkiewicz@gmail.com> [Fri, 19 Feb 2016 22:28:09 +0100] rev 28182
bookmarks: add 'hg push -B .' for pushing the active bookmark (
issue4917)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Feb 2016 15:56:44 -0800] rev 28181
worker: change partition strategy to every Nth element
The only consumer of the worker pool code today is `hg update`.
Previously, the algorithm to partition work to each worker process
preserved input list ordering. We'd take the first N elements, then
the next N elements, etc. Measurements on mozilla-central demonstrate
this isn't an optimal partitioning strategy.
I added debug code to print when workers were exiting. When performing
a working copy update on a previously empty working copy of
mozilla-central, I noticed that process lifetimes were all over the
map. One worker would complete after 7s. Many would complete after
12s. And another worker would often take >16s. This behavior occurred
for many worker process counts and was more pronounced on some than
others.
What I suspect is happening is some workers end up with lots of
small files and others with large files. This is because the update
code passes in actions according to sorted filenames. And, directories
under tend to accumulate similar files. For example, test directories
often consist of many small test files and media directories contain
binary (often larger) media files.
This patch changes the partitioning algorithm to select every Nth
element from the input list. Each worker thus has a similar composition
of files to operate on.
The result of this change is that worker processes now all tend to exit
around the same time. The possibility of a long pole due to being
unlucky and receiving all the large files has been mitigated. Overall
execution time seems to drop, but not by a statistically significant
amount on mozilla-central. However, repositories with directories
containing many large files will likely show a drop.
There shouldn't be any regressions due to partial manifest decoding
because the update code already iterates the manifest to determine
what files to operate on, so the manifest should already be decoded.