bundle2 is the new and preferred wire protocol format. For various
reasons, server operators may wish to force clients to use it.
One reason is performance. If a repository is stored in generaldelta,
the server must recompute deltas in order to produce the bundle1
changegroup. This can be extremely expensive. For mozilla-central,
bundle generation typically takes a few minutes. However, generating
a non-gd bundle from a generaldelta encoded mozilla-central requires
over 30 minutes of CPU! If a large repository like mozilla-central
were encoded in generaldelta and non-gd clients connected, they could
easily flood a server by cloning.
This patch gives server operators config knobs to control whether
bundle1 is allowed for push and pull operations. The default is to
support legacy bundle1 clients, making this patch backwards compatible.
New ui.graphnodetemplate option allows us to colorize a node symbol by phase
or branch,
[ui]
graphnodetemplate = {label('graphnode.{phase}', graphnode)}
[color]
graphnode.draft = yellow bold
or use a variety of unicode emoji characters, and so on. (You'll need less-481
to display non-BMP unicode character.)
[ui]
graphnodetemplate = {ifeq(obsolete, 'stable', graphnode, '\xf0\x9f\x92\xa9')}
Since we have pushed back the performance issue related to general delta behind
another configuration (Still off by default), we can safely create new
repository with general delta support. As client are compatible with it since
Mercurial 1.9 (4.5 years ago) I do no expect any significant compatibility
issues.
This option will make repositories created as general delta by default but will
not make Mercurial aggressively recompute deltas for all incoming bundle.
Instead, the delta contained in the bundle will be used. This will allow us to
start having general delta repositories created everywhere without triggering
massive recomputation costs for all new clients cloning from old servers.
Very often in my life I'm finding that the only configured merge tool
present on the system is vimdiff[0], and it's currently impossible (as
far as I can tell) short of specifying `ui.merge = `[1] to actually
*disable* a merge tool. This allows vimdiff-haters to put:
[merge-tools]
vimdiff.disable = yes
in their ~/.hgrc and never see vimdiff again. I'm stopping short of
putting this as a commented out entry in the sample new user hgrc
(seen when a user runs `hg config --edit` with no ~/.hgrc) for now,
but I might come back and do that later.
0: vimdiff is at an awkward intersection: it's usually installed by
the vim package which is often installed as a vi substitute, so it's
mere presence doesn't imply me wanting it, unlike (say) kdiff3.
1: There's a related problem I ran into today where specifying
`ui.merge = :merge` failed because :merge isn't a command, which I
think is a regression. I'll try and figure that out and at least file
a bug.
On windows, hgrc.d/*.rc would not be read if mercurial.ini was found. That was
far from obvious from the documentation and different from the behavior on
posix systems.
As a consequence of this, TortoiseHg cacert configuration placed in hgrc.d
would not be read if an old global mercurial.ini still existed.
"hg config -g" could also crash when no global configuration files could be
found.
Instead, make windows behave like posix and read all global configuration
files.
The documentation was in a way right that individual config settings in the
global Mercurial.ini would override settings from for example .hgrc.d\*.rc, but
only because the .d files not would be read at all if a Mercurial.ini was
found. The ordering in the documentation is thus changed to match the code.
Cloning can be an expensive operation for servers because the server
generates a bundle from existing repository data at request time. For
a large repository like mozilla-central, this consumes 4+ minutes
of CPU time on the server. It also results in significant network
utilization. Multiplied by hundreds or even thousands of clients and
the ensuing load can result in difficulties scaling the Mercurial server.
Despite generation of bundles being deterministic until the next
changeset is added, the generation of bundles to service a clone request
is not cached. Each clone thus performs redundant work. This is
wasteful.
This patch introduces the "clonebundles" extension and related
client-side functionality to help alleviate this deficiency. The
client-side feature is behind an experimental flag and is not enabled by
default.
It works as follows:
1) Server operator generates a bundle and makes it available on a
server (likely HTTP).
2) Server operator defines the URL of a bundle file in a
.hg/clonebundles.manifest file.
3) Client `hg clone`ing sees the server is advertising bundle URLs.
4) Client fetches and applies the advertised bundle.
5) Client performs equivalent of `hg pull` to fetch changes made since
the bundle was created.
Essentially, the server performs the expensive work of generating a
bundle once and all subsequent clones fetch a static file from
somewhere. Scaling static file serving is a much more manageable
problem than scaling a Python application like Mercurial. Assuming your
repository grows less than 1% per day, the end result is 99+% of CPU
and network load from clones is eliminated, allowing Mercurial servers
to scale more easily. Serving static files also means data can be
transferred to clients as fast as they can consume it, rather than as
fast as servers can generate it. This makes clones faster.
Mozilla has implemented similar functionality of this patch on
hg.mozilla.org using a custom extension. We are hosting bundle files in
Amazon S3 and CloudFront (a CDN) and have successfully offloaded
>1 TB/day in data transfer from hg.mozilla.org, freeing up significant
bandwidth and CPU resources. The positive impact has been stellar and
I believe it has proved its value to be included in Mercurial core. I
feel it is important for the client-side support to be enabled in core
by default because it means that clients will get faster, more reliable
clones and will enable server operators to reduce load without
requiring any client-side configuration changes (assuming clients are
up to date, of course).
The scope of this feature is narrowly and specifically tailored to
cloning, despite "serve pulls from pre-generated bundles" being a valid
and useful feature. I would eventually like for Mercurial servers to
support transferring *all* repository data via statically hosted files.
You could imagine a server that siphons all pushed data to bundle files
and instructs clients to apply a stream of bundles to reconstruct all
repository data. This feature, while useful and powerful, is
significantly more work to implement because it requires the server
component have awareness of discovery and a mapping of which changesets
are in which files. Full, clone bundles, by contrast, are much simpler.
The wire protocol command is named "clonebundles" instead of something
more generic like "staticbundles" to leave the door open for a new, more
powerful and more generic server-side component with minimal backwards
compatibility implications. The name "bundleclone" is used by Mozilla's
extension and would cause problems since there are subtle differences
in Mozilla's extension.
Mozilla's experience with this idea has taught us that some form of
"content negotiation" is required. Not all clients will support all
bundle formats or even URLs (advanced TLS requirements, etc). To ensure
the highest uptake possible, a server needs to advertise multiple
versions of bundles and clients need to be able to choose the most
appropriate from that list one. The "attributes" in each
server-advertised entry facilitate this filtering and sorting. Their
use will become apparent in subsequent patches.
Initial inspiration and credit for the idea of cloning from static files
belongs to Augie Fackler and his "lookaside clone" extension proof of
concept.
This allows the latest class of tag to be found, such as a release candidate or
final build, instead of just the absolute latest.
It doesn't appear that the existing keyword can be given an optional argument.
There is a keyword, function and filter for 'date', so it doesn't seem harmful
to introduce a new function with the same name as an existing keyword. Most
functions are pretty Mercurial agnostic, but there is {revset()} as precedent.
Even though templatekw.getlatesttags() returns a single tuple, one entry of
which is a list, it is simplest to present this as a list of tags instead of a
single item, with each tag having a distance and change count attribute. It is
also closer to how {latesttag} returns a list of tags, and how this function
works when not given a '%' operator.
The extensions blaming code is fine for casual users but pretty terrible for
corporate environments that can deploy a large amount of extensions to
unsuspecting users. Reports will likely blame a random "innocent" extension (in
our case crecord) and the hint in the message will triggers endless debug
attempts from the user.
We introduce a "ui.supportcontact" option that allow such big company to redirect
their users to their own support desk. This disables all extensions blaming and
just point people to the local support in all cases.
Because revset() function generates a list of revisions, it seems sensible
to switch the ctx as well where a list expression will be evaluated. I think
"{revset(...) % "..."}" expression wasn't considered well when it was
introduced at 45e0e191755f.
This breaks building manpages, and by association breaks building
debs. timeless has a fix coming, but it turns out we'll need to back
out dc22f967e9b0 anyway, so just back it out now to fix building
packages.
The keyword extension uses "utcdate" for a different function, so we can't
add new "utcdate" filter or function. Instead, this patch extends "localdate"
to a general timezone converter.
hgwebdir refreshes the set of known repositories periodically. This
is necessary because refreshing on every request could add significant
request latency.
More than once I've found myself wanting to tweak this interval at
Mozilla. I've also wanted the ability to always refresh (often when
writing tests for our replication setup).
This patch makes the refresh interval configurable. Negative values
indicate to always refresh. The default is left unchanged.
There are a lot of non-human consumers of Mercurial. And the challenges
and considerations for machines consuming Mercurial is significantly
different from what humans face.
I think there are enough special considerations around how machines
consume Mercurial that a dedicated help topic is warranted. I concede
the audience for this topic is probably small compared to the general
audience. However, lots of normal Mercurial users do things like create
one-off shell scripts for common workflows that I think this is useful
enough to be in the install (as opposed to, say, a wiki page - which
most users will likely never find).
This text is by no means perfect. But you have to start somewhere. I
think I did cover the important parts, though.
Well-behaved Mercurial clients will respect the httpheader capability by not
sending http headers longer than the given limit in bytes. The limit is
currently hard-coded at 1024 bytes, a safe value for any web server.
Since parsing headers is a notable factor in web server performance, tuning
header size can nontrivially improve performance for request-heavy operations
(eg. obsolete marker negotiation). Exposing the maximum header length limit
as a configuration setting is a simple way to enable such tuning.
This patch series is intended to unify the interpretation of string literals.
It is breaking change that boldly assumes
a. string literal "..." never contains template-like fragment or it is
intended to be a template
b. we tend to use raw string literal r"..." for regexp pattern in which "{"
should have different meaning
Currently, we don't have a comprehensible rule how string literals are
evaluated in template functions. For example, fill() takes "initialindent"
and "hangindent" as templates, but not for "text", whereas "text" is a
template in pad() function.
date(date, fmt)
diff(includepattern, excludepattern)
fill(text, width, initialident: T, hangindent: T)
get(dict, key)
if(expr, then: T, else: T)
ifcontains(search, thing, then: T, else: T)
ifeq(expr1, expr2, then: T, else: T)
indent(text, indentchars, firstline)
join(list, sep)
label(label: T, expr: T)
pad(text: T, width, fillchar, right)
revset(query, formatargs...])
rstdoc(text, style)
shortest(node, minlength)
startswith(pattern, text)
strip(text, chars)
sub(pattern, replacement, expression: T)
word(number, text, separator)
expr % template: T
T: interpret "string" or r"rawstring" as template
This patch series adjusts the rule as follows:
a. string literal, '' or "", starts template processing (BC)
b. raw string literal, r'' or r"", disables both \-escape and template
processing (BC, done by subsequent patches)
c. fragment not surrounded by {} is non-templated string
"ccc{'aaa'}{r'bbb'}"
------------------ *: template
--- c: string
--- a: template
--- b: rawstring
Because this can eliminate the compilation of template arguments from the
evaluation phase, "hg log -Tdefault" gets faster.
% cd mozilla-central
% LANG=C HGRCPATH=/dev/null hg log -Tdefault -r0:10000 --time > /dev/null
before: real 4.870 secs (user 4.860+0.000 sys 0.010+0.000)
after: real 3.480 secs (user 3.440+0.000 sys 0.030+0.000)
Also, this will allow us to parse nested templates at once for better error
indication.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
This hook will be called whenever a transaction is aborted. This will make it
easy for people to clean up temporary content they may have created during a
transaction.
Paths into the subrepo are not yet supported.
The need to use the workingctx in the subrepo will likely be used more in the
future, with the proposed working directory revset symbol. It is also needed
with archive, if that code is to be reused to support 'extdiff -S'.
Unfortunately, it doesn't seem possible to put the smarts in subrepo.subrepo(),
as it breaks various status and diff tests.
I opted not to pass the desired revision into the subrepo method explicitly,
because the only ones that do pass an explicit revision are methods like status
and diff, which actually operate on two contexts- the subrepo state and the
explicitly passed revision.
We are adding a 'txnclose' hook that will be run right before a transaction is
closed. Hooks running at that time will have access to the full transaction
content through both 'hookargs' content and on-disk reading. They will be able
to abort the transaction.
We are adding generic hooking for all transactions. We may have useful
information about what happened during the transaction, user of the transaction
should have filled the 'hookargs' dictionnary of the transaction. This hook is
simple because it has no power to rollback the transaction.
We are adding generic hooking for all transactions. We do not really have any
useful information to include when opening the transaction but this is a
useful time to allow a hook anyway. We better let people abort transaction before
they happen than after multiple seconds/minutes of processing.
The capabilities and URL endpoints of the hgweb server can currently
only be inferred by looking at links in `hg serve` output or by reading
the source code. I've frequently found myself wanting to quickly see
what URLs and capabilities are available.
This patch teaches the help system how to display information about
web commands and their URLs. Using a mechanism similar to revsets,
templates, etc, we can now iterate over the docstrings of registered
web command functions and display them in the help output.
Unfortunately, web commands don't currently have docstrings, so the
output is currently empty. This will be addressed in the following
patches. I apologize for the patch bomb.
V2: use 'self._ctx.node()' instead of 'rev' in makefileobj.
As Matt Harbison mentioned, using 'rev' does not make sense,
since we'd be passing a git revision to the top-level
Mercurial repository.
Before this patch, there is no way to concatenate strings at runtime.
For example, to search for the issue ID "1234" in descriptions against
all of "issue 1234", "issue:1234", issue1234" and "bug(1234)"
patterns, the revset below should be written fully from scratch for
each issue ID.
grep(r"\bissue[ :]?1234\b|\bbug\(1234\)")
This patch introduces new infix operator "##" to concatenate
strings/symbols at runtime. Operator symbol "##" comes from the same
one of C pre-processor. This concatenation allows parametrizing a part
of strings in revset queries.
In the case of example above, the definition of the revset alias using
operator "##" below can search issue ID "1234" in complicated patterns
by "issue(1234)" simply:
issue($1) = grep(r"\bissue[ :]?" ## $1 ## r"\b|\bbug\(" ## $1 ## r"\)")
"##" operator does:
- concatenate not only strings but also symbols into the string
Exact distinction between strings and symbols seems not to be
convenience, because it is tiresome for users (and
"revset.getstring" treats both similarly)
For example of revset alias "issue()", "issue(1234)" is easier
than "issue('1234')".
- have higher priority than any other prefix, infix and postfix
operators (like as "##" of C pre-processor)
This patch (re-)assigns the priority 20 to "##", and 21 to "(",
because priority 19 is already assigned to "-" as prefix "negate".
Previously these would be considered to be relative to the current working
directory. That behavior is both undocumented and doesn't really make sense.
There are two reasonable options for how to resolve relative paths:
- relative to the repo root
- relative to the config file
Resolving these files relative to the repo root matches existing behavior with
hooks. An earlier discussion about this is available at
http://mercurial.markmail.org/thread/tvu7yhzsiywgkjzl.
Thanks to Isaac Jurado <diptongo@gmail.com> for the initial patchset that
spurred the discussion.
Git and svn subrepos are currently not supported. It doesn't look like git or
svn have these commands natively, so that's an area for a git or svn expert.
The recursive addremove operation occurs completely before the first subrepo is
committed. Only hg subrepos support the addremove operation at the moment- svn
and git subrepos will warn and abort the commit.
So far, git subrepositories were silently ignored for diffs.
This patch adds support for git subrepositories,
with the remark that --include and --exclude are not supported.
If --include or --exclude are used, the subrepo is ignored.
Like 'forget', git and svn subrepos are currently not supported. Unfortunately
the name 'remove' is already used in the subrepo classes, so we break the
convention of naming the subrepo function after the command.
In an upcoming patch we'll enable support as an option to 'hg diff' as well.
The tests reflect the current state of the world -- as we add support we'll see
changes in the test output.
This helps providing a more consistent user experience on all platforms and
with all packaging.
The exact location of default.d depends on how Mercurial is installed and
whether it is 'frozen'. The exact location should never be relevant to users
and is intentionally not explained in details in the documentation. It will
however always be next to the help and templates files.
Note that setting HGRCPATH also disables these defaults. I don't know if that
should be considered a bug or a feature.
Since ce44c3c7c2be, we have a diff.nobinary option. This is handy, but
the only way I found out about it was by looking at the release notes
for 3.1, which is not something I normally do.
"diff" allows to embed changes in the target revision into template
output, even if the command itself doesn't take "--patch" option
Combination of "[committemplate]" configuration and "diff" template
function can achieve the feature like issue231 ("option to have diff
displayed in commit editor buffer")
http://bz.selenic.com/show_bug.cgi?id=231
For example, templating below can be used to add each "diff" output
lines "HG: " prefix::
{splitlines(diff) % 'HG: {line}\n'}
This patch implements "diff" not as "a template keyword" but as "a
template function" to take include/exclude patterns at runtime.
It allows to specify target files of command (by -I/-X command line
options) and "diff" separately.
"editform" argument for "getcommiteditor" is decided according to the
format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch newly adds "normal" and "merge" as ROUTE, to distinguish
merge commits from other.
This patch adds 4 test patterns to test combination of "merge"(x2) and
"--continue"(x2).
"editform" argument for "getcommiteditor" is decided according to the
format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch newly adds "merge" as ROUTE, to distinguish merge commits
from other.
This patch passes bool as "ctxorbool" to "mergeeditform", because
working context has always 2 parents at this point. Dropping the
second parent of non-merging commits is executed in "concludenode".
Unlike other patches in this series (e.g. for "hg commit"), this patch
doesn't add "normal.normal"/"normal.merge" style ROUTEs, because there
is no "merge" case in "collapse" ROUTE.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
other in "hg import" without "--bypass" case.
This patch assumes "editform" variations for "hg import" below:
import.normal.normal
import.normal.merge
import.bypass.normal
import.bypass.merge
Unlike other patches in this series, this patch uses "editor.sh"
instead of "checkeditform.sh" for the name of the script to check
"HGEDITFORM", because it has to do more than checking "HGEDITFORM".
To invoke editor forcibly in "test-import-merge.t", this patch creates
the patch not having patch description as "merge.nomsg.diff".
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "amend.normal" and "amend.merge" as ROUTE of
"editform" instead of "amend", to distinguish merge commits from other
in "hg commit --amend" case.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
others in "hg commit" without "--amend" case.
This patch assumes "editform" variations for "hg commit" below:
commit.normal.normal
commit.normal.merge
commit.amend.normal
commit.amend.merge
"mergeeditform" is factored out for subsequent patches. It takes
"ctxorbool" argument, because context object can't be passed in some
cases.
At the external editor invocation for committing, the value specified
as "editform" for "cmdutil.getcommiteditor" is in "HGEDITFORM".
This enables external editor to do own customization according to
commit types.
Before this patch, there was no way to pass in all the positional parameters as
separate words down to another command.
(1) $@ (without quotes) would expand to all the parameters separated by a space.
This would work fine for arguments without spaces, but arguments with spaces
in them would be split up by POSIX shells into separate words.
(2) '$@' (in single quotes) would expand to all the parameters within a pair of
single quotes. POSIX shells would then treat the entire list of arguments
as one word.
(3) "$@" (in double quotes) would expand similarly to (2).
With this patch, we expand "$@" (in double quotes) as all positional
parameters, quoted individually with util.shellquote, and separated by spaces.
Under standard field-splitting conditions, POSIX shells will tokenize each
argument into exactly one word.
This is a backwards-incompatible change, but the old behavior was arguably a
bug: Bourne-derived shells have expanded "$@" as a tokenized list of positional
parameters for a very long time. I could find this behavior specified in IEEE
Std 1003.1-2001, and this probably goes back to much further before that.
Before this patch, each template definitions for 'changeset*' in
'[committemplate]' section have to be written fully from scratch,
even though many parts of them may be common.
This patch uses '[committemplate]' section like as the map file for
the style definition. All items other than 'changeset' can be referred
from others.
This can reduce total cost of template customization in
'[committemplate]' section.
When the commit template other than '[committemplate] changeset'
is chosen by 'editform', putting '[committemplate] changeset'
value into the cache of the templater causes unexpected result,
because the templater stores the specified (= chosen) template
definition into own cache as 'changeset' at construction time.
This is the reason why '[committemplate] changeset' can't be referred
from others.
Before this patch, '[committemplate] changeset' definition is shared
between all actions invoking 'commitforceeditor()'.
This prevents template definition from showing action specific
messages: for example, 'hg tag --remove' may need specific
message to call attention, but showing it may be redundant for
other actions.
This patch looks commit template definition up by specified
'editform' introduced by prior patches. 'editform' are
dot-separated list of names, and treated as hierarchical one.
This patch makes commit message shown in text editor customizable by
template. For example, this can advertise:
- sample commit messages for routine works,
- points to call attention before commit,
- message of the day, and so on
To show commit message correctly even in problematic encoding, this
patch chooses the latter below:
- replace "buildcommittext" with "buildcommittemplate" completely
- invoke "buildcommittemplate" only if '[committemplate] changeset'
is configured explicitly
For example, if multibyte character ending with backslash (0x5c) is
followed by ASCII character 'n' in the customized template, sequence
of backslash and 'n' is treated as line-feed unexpectedly (and
multibyte character is broken, too).
This corruption occurs in 'decode("string-escape")' while parsing
template string.
Before this patch, 'detailed' is used as the default of '[ui]
mergemarkers'. This embeds non-ASCII characters in tags, branches,
bookmarks, author and/or commit descriptions into merged files in the
encoding specified by '--encoding' global option, 'HGENCODING' or
other locale setting environment variables.
But, if files to be merged use another encoding, this behavior breaks
consistency of encoding in merged files.
For example, ISO-2022-JP or EUC-JP are sometimes used as the file
encoding for Japanese characters, because of historical and/or
environmental reasons, even though UTF-8 or Shift-JIS are ordinarily
used as the terminal encoding.
This can't be resolved automatically, because Mercurial doesn't aware
encoding of managed files.
This patch uses 'basic' as the default of '[ui] mergemarkers' to avoid
embedding encoding sensitive characters for safety.
This patch puts '[ui] mergemarkers = detailed' into default hgrc file
for tests, to reduce changes for tests in this patch.
This function allows returning only the nth "word" from a string. By default
a string is split as by Python's split() function default, but an optional
third parameter can also override what string the string is split by.
This function returns a string only if it starts with a given string.
It is particularly useful when combined with splitlines and/or used with
conditionals that fail when empty strings are passed in to take action
based on the contents of a line.
This is useful for applying changes to each line, and it's especially powerful
when used in conjunction with conditionals to modify lines based on content.
Adds a conflict marker formatter that can produce custom conflict marker
descriptions. It can be set via ui.mergemarkertemplate. The old behavior
can be used still by setting ui.mergemarkers=basic.
The default format is similar to:
{node|short} {tag} {branch} {bookmarks} - {author}: "{desc|firstline}"
And renders as:
contextblahblah
<<<<<<< local: c7fdd7ce4652 - durham: "Fix broken stuff in my feature branch"
line from my changes
=======
line from the other changes
>>>>>>> other: a3e55d7f4d38 master - sid0: "This is a commit to master th...
morecontextblahblah
We highlight the fact that a user hgrc can overwrite the system wide
preconfiguration. As other benefit we show priority value other than 1 and shows
vimdiff configuration is usually directly available. This is valuable as vimdiff
is (surprisingly) a common request from user.
The merge tool configuration in general has always been a confusing topic for
user. We add mention of:
- possible pre-existing configuration,
- way to look at it,
- the more detailed help topic about how merge-tools configuration works.
This should help users find they way.
The cat command with an explicit path into a subrepo is now handled by invoking
cat on the file, from that subrepo. The previous behavior was to complain that
the file didn't exist in the revision (of the top most repo). Now when the file
is actually missing, the revision of the subrepo is named instead (though it is
probably desirable to continue naming the top level repo).
The documented output formatters %d and %p reflect the path from the top level
repo, since the purpose of this is to give the illusion of a unified repository.
Support for the undocumented (for cat) formatters %H, %R, %h, %m and %r was
added long ago (I tested back as far as 0.5), but unfortunately these will
reflect the subrepo node instead of the parent context.
The previous implementation was a bit loose with the return value, i.e. it would
return 0 if _any_ file requested was cat'd successfully. This maintains that
behavior.
When we add two newlines after ".. note::" translators will not see this
entry. And all versions of docutils interpret this paragraph correctly
(details in 89e31d6e438f).
The certificate was updated in February 2014.
You can verify the certificate by using the Root CA certificate downloadable
from https://ssl.intevation.de/
The intermediate CA is sent by https://hg.intevation.org/
This fixes mistake of documentation about matching against directories
in "pattern.txt" introduced by b99923dc748f.
".hgignore" treats specified "glob:" pattern as same as one specified
for "-X" option: it can match against directories, too.
For reference, extra regexp string appended to specified pattern for
each types are listed below: see also "match.match()" and
"match._regex()" for detail.
============= ========== ===============
type cmdline -I/-X
============= ========== ===============
glob/relglob '$' '(?:/|$)'
path/relpath '(?:/|$)' '(?:/|$)'
re/relre (none) (none)
============= ========== ===============
Appending '$' means that the specified pattern should match against
only files.
For technical reason (discovery, obsolescence marker) the hash of secret
changeset are communicated outside of your repo. We clarifie that in the help so
that people does not used hash of secret changeset as nuclear launch code.
Before this patch, there is no explicit description about pattern
matching against directories, even though users may understand it from
"plain examples" in "hg help patterns".
This patch adds description about pattern matching against
directories.
Was the behavior correct and the description wrong so it should be updated as
in this patch? Or should the code work as the documentation says?
Both ways could make some sense ... but none of them are obvious in all cases.
One place where it currently cause problems is when the current revision has
another branch head that is closer to tip but closed. 'hg rebase' refuses to
rebase to that as it only see the tip-most unclosed branch head which is the
current revision.
/me kind of likes named branches, but no so much how branch closing works ...
Before this patch, phase of newly created commit is determined by
"phases.new-commit" configuration regardless of phase of state in each
subrepositories.
For example, this may cause the "public" revision in the parent
repository referring the "secret" one in subrepository.
This patch checks phase of state in each subrepositories before
committing in the parent, and aborts or changes phase of newly created
commit if subrepositories have more restricted phase than the parent.
This patch uses "follow" as default value of "phases.checksubrepos"
configuration, because it can keep consistency between phases of the
parent and subrepositories without breaking existing tool chains.
On Windows, only double quotation mark can quote command line
arguments.
So, this patch uses double quotation mark to quote command line
arguments in all examples of online help document.
We tell people all the time that enabling extensions is not a scary
thing to do, but we don't make it easy enough for an absolute novice
to do so. When they see a suggestion to do "hg extfoo bar", the error
message tells them "see hg help extensions", but that help page
doesn't actually tell them where configuration files are.
Furthermore, the big warning about why extensions aren't enabled by
default should be pushed down a little bit. Most of the extensions
shipped by hg are not all that scary, and some very basic and useful
cosmetic extensions like graphlog, color, pager, and progress, should
be enabled for many hg users.
While we do use the abbreviation "config" elsewhere in the docs, the
phrase "configuration file" is always written out in full, except in
this location in phases.txt.
Markup for links to mercurial commands is appearing in the help
documentation.
This patch fixes the markup so mercurial command reference links are
correctly generated in the help documentation.
Before this patch the only place that documented the use of a different
registry key was on the wiki page for installing on Windows from
sources, while most users will use a pre-packaged installer and the
supplied help files.
This patch documents in the supplied help files that an alternate
registry key is used for the installation/system configuration file when
using 32-bit Python on a 64-bit Windows.
Before this patch, port 25 (wellknown port of SMTP) is used as default
port, even if "[smtp] tls" is configured as "smtps".
This patch uses port 465 (wellknown port of SMTPS) as default port, if
"[smtp] tls" is configured as "smtps".
There is a new style called phases style.
Usage::
hg log --style phases
Why do we need this new style - in what way is it different from or similar to
existing styles?
The new style is default + phases information. With the new phases feature the
users exhibited their desire for a new style that could help them.
Why do this need a new style - couldn't it be folded into an existing style?
The default style and the new one are about the same, the difference is the
phases tag. The users find both styles useful, this means that the both styles
must exist.
Before this patch, the certificate of the SMTP server for STARTTLS or
SMTPS isn't verified.
This may cause man-in-the-middle security problem (stealing
authentication information), even though SMTP channel itself is
encrypted by SSL.
When "[smtp] tls" is configured as "smtps" or "starttls", this patch:
- uses classes introduced by preceding patches instead of "SMTP" or
"SMTP_SSL" of smtplib, and
- verifies the certificate of the SMTP server, if "[smtp]
verifycert" is configured as other than False
"[smtp] verifycert" can be configured in 3 levels:
- "strict":
This verifies peer certificate, and aborts if:
- peer certification is not valid, or
- no configuration in "[hostfingerprints]" and "[web] cacerts"
This is default value of "[smtp] verifycert" for security.
- "loose":
This verifies peer certificate, and aborts if peer certification is
not valid.
This just shows warning message ("certificate not verified"), if
there is no configuration in "[hostfingerprints]" and "[web]
cacerts".
This is as same as verification for HTTPS connection.
- False(no verification):
Peer certificate is not verified.
This is as same as the behavior before this patch series.
"hg email --insecure" uses "loose" level, and ignores "[web] cacerts"
as same as push/pull/etc... with --insecure.
Ignoring "[web] cacerts" configuration for "hg email --insecure" is
already done in "dispatch._dispatch()" by looking "insecure" up in the
table of command options.
The certificate was updated in March 2012.
You can verify the certificate by using the Root CA certificate downloadable
from https://ssl.intevation.de/
The intermediate CA is sent by https://hg.intevation.org/
In order to use this, add a [websub] section to your configuration and add
websub expressions such as:
italic = s/\b_(\S+)_\b/<i>\1<\/i>/
bold = s/\*\b(\S+)\b\*/<b>\1<\/b>/
issues = s|issue(\d+)|<a href="http://bts.example.org/issue\1">issue\1</a>|i
bugzilla = s!((?:bug|b=|(?=#?\d{4,}))(?:\s*#?)(\d+))!<a href="http://bz.selenic.com/\2">\1</a>!i
This also adds documentation (proofed by Kevin!) to the config help section.
The display of nested lines for hg --profile was very non-obvious and made it
look like sort didn't work.
The '+' immediately before CallCount was not related to the CallCount and did
not mean plus in any integer sense.
The '+' before module looked like a part of the module name and not like ascii
art.
Instead we now indent the subordinate module names to clearly show the
structure.
The number of output lines was hardcoded to 30.
There was a 'nested' configuration options that controlled something else
related to counting the number of output lines.
This introduces the profiling.limit configuration option for controlling the
number of profiling output to show.
Adding support to parsedate in util module to understand the more idiomatic
dates 'today' and 'yesterday'.
Added unified tests and docstring tests for added functionality.
These settings were replaced by check=changed and check=conflicts in
9b0e7e973592. There is no reason to announce two different ways to achieve the
same. The old way should be kept but not announced.
Currently when obtaining an archive snapshot of a repository via the
web interface, subrepositories are not taken in the snapshot. I
introduce an option, archivesubrepos, which allows this.
Some help topics use "-" for the top level underlining section mark,
but "-" is used also for the top level categorization in generated
documents: "hg.1.html", for example.
So, TOC in such documents contain "sections in each topics", too.
This patch changes underlining section mark in some help topics to
unify section level in generated documents.
After this patching, levels of each section marks are:
level0
""""""
level1
======
level2
------
level3
......
level4
######
And use of section markers in each documents are:
- mercurial/help/*.txt can use level1 or more
(now these use level1 and level2)
- help for core commands can use level2 or more
(now these use no section marker)
- descriptions of extensions can use level2 or more
(now hgext/acl uses level2)
- help for commands defined in extension can use level4 or more
(now "convert" of hgext/convert uses level4)
"Level0" is used as top level categorization only in "doc/hg.1.txt"
and the intermediate file generated by "doc/gendoc.py", so end users
don't see it in "hg help" outoput and so on.
Adds new web command to the core, ``comparison``, which enables colorful
side-by-side change display, which for some might be much easier to work with
than the standard line diff output. The idea how to implement comes from the
SonicHq extension.
The web interface gets a new link to call the comparison functionality. It lets
users configure the amount of context lines around change blocks, or to show
full files - check help (also in this changeset) for details and defaults. The
setting in hgrc can be overridden by adding ``context=<value>`` to the request
query string. The comparison creates addressable lines, so as to enable sharing
links to specific lines, just as standard diff does.
Incorporates updates to all web related styles.
Known limitations:
* the column diff is done against the first parent, just as the standard diff
* this change allows examining diffs for single files only (as I am not sure if
examining the whole changeset in this way would be helpful)
* syntax highlighting of the output changes is not performed (enabling the
highlight extension has no influence on it)
The existing help only walked through an example.
Now we first explain the basic rules and then show an example.
The 'collections' example and description only cause confusion and is removed.
Bikeshedded by Patrick Mezard <patrick@mezard.eu>
Since version 1.8 (released on 2011-03-01), Mercurial doesn't use pywin32 any
more. The old fallback mechanism to use C:\Mercurial\Mercurial.ini if pywin32 is
not installed was removed in 1fa0a833f143.
The collapse configuration setting for hgweb was recently
introduced, but the help text was unfortunately omitted from the
patch concerned. This patch provides a suitable help text.
Brifly explain why rewriting subrepository paths can be necessary.
Explain that relative subrepository paths are made absolute before
rewrite rules are applied.
It seem like docutils 0.8 interpret ':hg:`command`' roles at the beginning of
indented lines in '.. note::' directives as a field that is an invalid argument
to the directive. It fails with 'Error in "note" directive: invalid option
block.' Docutils 0.7 accepted this arguably incorrect markup.
Reflowing the text makes the problem go away. A leading '\ ' could perhaps also
be used to mask the problem.
each help topics describe that patterns are "not rooted" and "rooted"
in themselves, but not describe about each other.
so, this may causes misunderstanding about "rooted"-ness of patterns.
there is no term 'Changeset, close' in glossary.
'Close changeset' seems to have to be linked not to 'Branch, closed',
but to 'Head, closed branch', because only the latter explains about
"the changeset that marks a head as no longer interesting".
This can be selected using the config variable profiling.type or
the environment variable HGPROF ("ls" for the default, "stat" for
statprof). The only tuneable is the frequency, profiling.freq,
which defaults to 1000 Hz.
If statprof is not available, a warning is printed.
Some platforms, notably Plan 9 from Bell Labs are stuck on older
releases of Python. Due to restrictions in the platform, it is not
possible to backport the SSL library to the existing Python port.
This patch permits the UI to quiesce SSL verification warnings by
adding a configuration entry named reportoldssl to ui.
This patch contains support for Plan 9 from Bell Labs. A README is
provided in contrib/plan9 which describes the port in greater detail.
A new extension is also provided named factotum which permits the
factotum(4) authentication agent to provide credentials for HTTP
repositories. This extension is also applicable to other POSIX
platforms which make use of Plan 9 from User Space (aka plan9ports).
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 1
This makes pull agree with the rest of the table and makes it easy to
detect "nothing was pulled" in scripts.
