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.
