##// END OF EJS Templates
setdiscovery: make progress on most connected groups each roundtrip...
setdiscovery: make progress on most connected groups each roundtrip Consider history like this: o | o | | | o | | | o |/ o | o | | | o | | | o |/ o | o | | | o | | | o |/ o ~ Assume the left mainline is available in the remote repo and the other commits are only in the local repo. Also imagine that instead of 3 local branches with 3 commits on each, there are 1000 branches (the number of commits on each doesn't matter much here). In such a scenario, the current setdiscovery code will pick a sample size of 200 among these branches and ask the remote which of them it has. However, the discovery for each such branch is completely independent of the discovery for the others -- knowing whether the remote has a commit in one branch doesn't give us any information about the other branches. The discovery will therefore take at least 5 roundtrips (maybe more depending on which commit in each linear chain was sampled). Since the discovery for each branch is independent, there is no reason to let one branch wait for another, so this patch makes it so we sample at least as many commits as there are branches. It may still happen (it's very likely, even) that we get multiple samples from one branch and none from another, but that will even out over a few rounds and I think this is still a big improvement. Because of http header size limits, we still use the old behavior unless experimental.httppostargs=true. I've timed this by running `hg debugdiscovery mozilla-unified --debug` in the mozilla-try repo. Both repos were local. Before this patch, last part of the output was: 2249 total queries in 5276.4859s elapsed time: 5276.652634 seconds heads summary: total common heads: 13 also local heads: 4 also remote heads: 8 both: 4 local heads: 28317 common: 4 missing: 28313 remote heads: 12 common: 8 unknown: 4 local changesets: 2014901 common: 530373 missing: 1484528 common heads: 1dad417c28ad 4a108e94d3e2 4d7ef530fffb 5350524bb654 777e60ca8853 7d97fafba271 9cd2ab4d0029 a55ce37217da d38398e5144e dcc6d7a0dc00 e09297892ada e24ec6070d7b fd559328eaf3 After this patch, the output was (including all the samples, since there were so few now): taking initial sample query 2; still undecided: 1599476, sample size is: 108195 sampling from both directions query 3; still undecided: 810922, sample size is: 194158 sampling from both directions query 4; still undecided: 325882, sample size is: 137302 sampling from both directions query 5; still undecided: 111459, sample size is: 74586 sampling from both directions query 6; still undecided: 26805, sample size is: 23960 sampling from both directions query 7; still undecided: 2549, sample size is: 2528 sampling from both directions query 8; still undecided: 21, sample size is: 21 8 total queries in 24.5064s elapsed time: 24.670051 seconds heads summary: total common heads: 13 also local heads: 4 also remote heads: 8 both: 4 local heads: 28317 common: 4 missing: 28313 remote heads: 12 common: 8 unknown: 4 local changesets: 2014901 common: 530373 missing: 1484528 common heads: 1dad417c28ad 4a108e94d3e2 4d7ef530fffb 5350524bb654 777e60ca8853 7d97fafba271 9cd2ab4d0029 a55ce37217da d38398e5144e dcc6d7a0dc00 e09297892ada e24ec6070d7b fd559328eaf3 Differential Revision: https://phab.mercurial-scm.org/D2647

File last commit:

r39304:0dfcc348 default
r42594:5b34972a default
Show More
merge-tools.txt
109 lines | 4.4 KiB | text/plain | TextLexer
To merge files Mercurial uses merge tools.
A merge tool combines two different versions of a file into a merged
file. Merge tools are given the two files and the greatest common
ancestor of the two file versions, so they can determine the changes
made on both branches.
Merge tools are used both for :hg:`resolve`, :hg:`merge`, :hg:`update`,
:hg:`backout` and in several extensions.
Usually, the merge tool tries to automatically reconcile the files by
combining all non-overlapping changes that occurred separately in
the two different evolutions of the same initial base file. Furthermore, some
interactive merge programs make it easier to manually resolve
conflicting merges, either in a graphical way, or by inserting some
conflict markers. Mercurial does not include any interactive merge
programs but relies on external tools for that.
Available merge tools
=====================
External merge tools and their properties are configured in the
merge-tools configuration section - see hgrc(5) - but they can often just
be named by their executable.
A merge tool is generally usable if its executable can be found on the
system and if it can handle the merge. The executable is found if it
is an absolute or relative executable path or the name of an
application in the executable search path. The tool is assumed to be
able to handle the merge if it can handle symlinks if the file is a
symlink, if it can handle binary files if the file is binary, and if a
GUI is available if the tool requires a GUI.
There are some internal merge tools which can be used. The internal
merge tools are:
.. internaltoolsmarker
Internal tools are always available and do not require a GUI but will
by default not handle symlinks or binary files. See next section for
detail about "actual capabilities" described above.
Choosing a merge tool
=====================
Mercurial uses these rules when deciding which merge tool to use:
1. If a tool has been specified with the --tool option to merge or resolve, it
is used. If it is the name of a tool in the merge-tools configuration, its
configuration is used. Otherwise the specified tool must be executable by
the shell.
2. If the ``HGMERGE`` environment variable is present, its value is used and
must be executable by the shell.
3. If the filename of the file to be merged matches any of the patterns in the
merge-patterns configuration section, the first usable merge tool
corresponding to a matching pattern is used.
4. If ui.merge is set it will be considered next. If the value is not the name
of a configured tool, the specified value is used and must be executable by
the shell. Otherwise the named tool is used if it is usable.
5. If any usable merge tools are present in the merge-tools configuration
section, the one with the highest priority is used.
6. If a program named ``hgmerge`` can be found on the system, it is used - but
it will by default not be used for symlinks and binary files.
7. If the file to be merged is not binary and is not a symlink, then
internal ``:merge`` is used.
8. Otherwise, ``:prompt`` is used.
For historical reason, Mercurial treats merge tools as below while
examining rules above.
==== =============== ====== =======
step specified via binary symlink
==== =============== ====== =======
1. --tool o/o o/o
2. HGMERGE o/o o/o
3. merge-patterns o/o(*) x/?(*)
4. ui.merge x/?(*) x/?(*)
==== =============== ====== =======
Each capability column indicates Mercurial behavior for
internal/external merge tools at examining each rule.
- "o": "assume that a tool has capability"
- "x": "assume that a tool does not have capability"
- "?": "check actual capability of a tool"
If ``merge.strict-capability-check`` configuration is true, Mercurial
checks capabilities of merge tools strictly in (*) cases above (= each
capability column becomes "?/?"). It is false by default for backward
compatibility.
.. note::
After selecting a merge program, Mercurial will by default attempt
to merge the files using a simple merge algorithm first. Only if it doesn't
succeed because of conflicting changes will Mercurial actually execute the
merge program. Whether to use the simple merge algorithm first can be
controlled by the premerge setting of the merge tool. Premerge is enabled by
default unless the file is binary or a symlink.
See the merge-tools and ui sections of hgrc(5) for details on the
configuration of merge tools.