Currently we only support enabling TLS by using SMTP STARTTLS extension. But
not all the servers support it.
With this patch, user can choose which way to enable TLS:
* Default:
tls = none
port = 25
* To use STARTTLS:
tls = starttls
port = 465
* To use SMTP over SSL:
tls = smtps
port = 465
To keep backward compatibility, when tls = true, we use STARTTLS to enable TLS.
Signed-off-by: Zhigang Wang <w1z2g3@gmail.com>
By default, hgweb_mod supports caching via the ETag header. This can
cause some confusion with browsers which cache aggressively. This change
preserves existing behavior while giving the administrator a knob to
disable the ETag header.
Clicking on the logo image/text in the hgweb interface brings the
user to the Mercurial project page. The majority of users expect that
this would bring them to the top level index. I have added a new template
variable named `logourl' which allows an administrator to change this
behavior. To stay compatible with existing behavior, `logourl' will
default to http://mercurial.selenic.com/. This change is very useful in
large installations where jumping to the index is common.
On POSIX platforms, the 'add', 'addremove', 'copy' and 'rename' commands now
warn if a file has a name that can't be checked out on Windows.
Example:
$ hg add con.xml
warning: filename contains 'con', which is reserved on Windows: 'con.xml'
$ hg status
A con.xml
The file is added despite the warning.
The warning is ON by default. It can be suppressed by setting the config option
'portablefilenames' in section 'ui' to 'ignore' or 'false':
$ hg --config ui.portablefilenames=ignore add con.xml
$ hg sta
A con.xml
If ui.portablefilenames is set to 'abort', then the command is aborted:
$ hg --config ui.portablefilenames=abort add con.xml
abort: filename contains 'con', which is reserved on Windows: 'con.xml'
On Windows, the ui.portablefilenames config setting is irrelevant and the
command is always aborted if a problematic filename is found.
Why?
- Mercurial internal patcher works correctly for regular patches and git
patches, is much faster at least on Windows and is more extensible.
- In theory, the external patcher can be used to handle exotic patch formats. I
do not know any and have not heard about any such use in years.
- Most patch programs cannot handle git format patches, which makes the API
caller to decide either to ignore ui.patch by calling patch.internalpatch()
directly, or take the risk of random failures with valid inputs.
- One thing a patch program could do Mercurial patcher cannot is applying with
--reverse. Apparently several shelve like extensions try to use that,
including passing the "reverse" option to Mercurial patcher, which has been
removed mid-2009. I never heard anybody complain about that, and would prefer
reimplementing it anyway.
And from the technical perspective:
- The external patcher makes everything harder to maintain and implement. EOL
normalization is not implemented, and I would bet file renames, if supported
by the patcher, are not correctly recorded in the dirstate.
- No tests.
How?
- Remove related documentation
- Clearly mark patch.externalpatch() as private
- Remove the debuginstall check. This deprecation request was actually
triggered by this last point. debuginstall is the only piece of code patching
without a repository. When migrating to an integrated patch() + updatedir()
call, this was really a showstopper, all workarounds were either ugly or
uselessly complicated to implement. If we do not support external patcher
anymore, the debuginstall check is not useful anymore.
- Remove patch.externalpatch() after 1.9 release.
It is an intermediate file used to produce the hg.1 and .hg.1.html
files and is not useful for people who download the tarball. It will
be regenerated automatically by the Makefile if users want to rebuild
the documentation.
This was an old left-over from when the synopsis line was used as a
header. We now have the command name by itself as the header and the
synopsis as a literal block immediately after..
Adds a section in the hg.1 manpage and corresponding hg.1.html
file. Each extension is listed with its module docstring, followed by
the commands defined by that extendsion.
Creates help for extensions by extracting doc strings from the extension modules
and its commands.
When getting docstrings from the source they are indented to look good
in the code. This indentation interferes with how the text is parsed
by rst. Therefore this indentation is removed.
I have made a help topic for merge tools. The text in the topic is
based on the http://mercurial.selenic.com/wiki/MergeProgram page from
the wiki, along with some extra information on the internal merge tools.
Mads Kiilerich pointed out that 1e4ade283b02 was too eager since the
prefix and password keys may contain $-signs. So this only add the
username to the list of keys that are expanded.
This also updates the documentation to match.
python hooks are passed two new keyword arguments:
- opts: a dict of options; unsepcified options are set to their default
- pats: a list of arguments
shell hooks receive two new variables containing string representations
of the above data:
- $HG_OPTS
- $HG_PATS
for example, the opts and pats for 'hg -f v1.1' would be:
{'force': True, 'message': '', 'rev': '', 'user': '', 'date': '', 'local': None, 'remove': None, 'mq': None}
['v1.1']
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
tool.check is a list of check options, and can be used in place of
tool.checkchanged and tool.checkconflicts:
Equivalences:
tool.checkchanged = yes
tool.checkconflicts = no
tool.check = changed
tool.checkchanged = no
tool.checkconflicts = yes
tool.check = conflicts
tool.checkchanged = yes
tool.checkconflicts = yes
tool.check = changed, conflicts
Add _toollist() wrapper for ui.configlist() to implement this consistently.
checkchanged and checkconflicts are still supported, but check is
preferred for implementing new check options.
Several places that use ui.configlist, predominantly in authentication
scenarios need to interface with systems that can contain spaces in usernames
(e.g. when client certificates are usernames, or Windows usernames).
This changeset introduces a parser that supports quoting of strings, and
escape quotation marks that get decoded into a single quotation mark that
adopts the usual behavior one would expect from quoting strings. The Python
library shlex module is not used, on purpose, as that raises if it cannot
match quotation marks in the given input.
They were added way back in 2005 and haven't been updated since. They
are no longer referenced by the Makefiles at upper levels and have not
been shipped with a recent version of Mercurial.
Displaying the output from the failing call to "which" didn't prevent
make from doing stupid things later. We now only search for "rst2html"
and fallback to "rst2html.py". If neither name is found, make will
eventually abort when we try to use $(RST2HTML).
The man pages can actually be translated by building them in a
different locale. However, the man pages contain internal links to
certain sections, and when the section titles are translated, the
links change too. So it is currently not recommended to build the man
pages in anything by the "C" locale.
* it's bad to specify only foreground color:
http://www.w3.org/QA/Tips/color
* some people prefer dark background
* `color: #111' is mostly the same as `color: black',
which is the default of almost all popular browsers.
so it's preferable to delete `color: #111', rather than adding
`background-color: white'.
designed loosely based on:
http://mercurial.selenic.com/css/styles.css
with some modifications by intention:
* visited links are colored differently
* no fixed size
* works without typeface.js
we keep most styles, which is from docutils, untouched.
tested with:
* MSIE 6.0 on Windows
* Firefox 3.5 on Linux
Man pages have uppercased section titles but other formats do not.
Letting rst2man handle the tranformation allows better reuse of text
between man pages and other formats.