- Dec 06, 2011
-
-
Olav Reinert authored
-
- Oct 20, 2011
-
-
Martin Geisler authored
Peter Toft told me he had installed a 'python-doc' package instead of the correct 'python-docutils' and he suggested that we add the URL to Docutils in our error message.
-
- Jul 25, 2011
-
-
Augie Fackler authored
-
- Jun 29, 2011
-
-
Thomas Arendsen Hein authored
This makes test-wireprotocol.py work on Python 2.4
-
- Jun 16, 2011
-
-
Satish Balay authored
-
- May 30, 2011
-
-
Martin Geisler authored
-
Martin Geisler authored
-
Martin Geisler authored
-
Yun Lee authored
-
Yun Lee authored
The minirst parser is stricter than Docutils here and require a blank after a heading. Otherwise the heading is classified as a paragraph.
-
- May 13, 2011
-
-
Matt Mackall authored
This is a bad/silly API. Instead calculate maxlength in one place in help it's used and simplify all the callers.
-
- May 09, 2011
-
-
Martin Geisler authored
-
Martin Geisler authored
-
Martin Geisler authored
-
- May 01, 2011
-
-
Adrian Buehlmann authored
-
Brodie Rao authored
-
- Apr 17, 2011
-
-
Yun Lee authored
-
- Apr 20, 2011
-
-
Steven Stallion authored
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.
-
Steven Stallion authored
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.
-
- Apr 19, 2011
-
-
Adrian Buehlmann authored
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.
-
- Apr 07, 2011
-
-
Martin Geisler authored
-
Martin Geisler authored
The first paragraph apply to all extensions, not just those in hgext. The second paragraph can just use the simpler form to load mq.
-
- Mar 24, 2011
-
-
Patrick Mezard authored
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.
-
- Mar 08, 2011
-
-
Steve Borho authored
This allows us to provide alternate search keys for 64bit operating systems that may have 32bit merge tools installed. Presumably it may find other uses.
-
- Feb 15, 2011
-
-
Patrick Mezard authored
The default behaviour is to commit subrepositories with uncommitted changes. In my experience this is usually undesirable: - Changes to dependencies are often debugging leftovers - Real changes should generally be applied on the source project directly, tested then committed. This is not always possible, subversion subrepos may include only a small part of the source project, without the tests. Setting ui.commitsubrepos=no will now abort commits containing such modified subrepositories like: $ hg --config ui.commitsubrepos=no ci -m msg abort: uncommitted changes in subrepo sub I ruled out the hook solution because it does not easily take --include/exclude options in account. Also, my main concern is whether this flag could cause problems with extensions. If there are legitimate reasons for callers to override this behaviour (I could not find any), they might either override at ui level, or we could add an argument to localrepo.commit() later. v2: - Renamed ui.commitsubs to ui.commitsubrepos - Mention the configuration entry in hg help subrepos
-
- Feb 11, 2011
-
-
Afuna authored
-
- Feb 05, 2011
-
-
Javi Merino authored
-
- Feb 01, 2011
-
-
kiilerix authored
-
- Jan 29, 2011
-
-
Yuya Nishihara authored
If --insecure specified, it behaves in the same way as no web.cacerts configured. Also shows hint for --insecure option when _verifycert() failed. But currently the hint isn't displayed on SSLError, because it needs a certain level of changes.
-
- Jan 28, 2011
-
-
kiilerix authored
-
kiilerix authored
Known fingerprints of HTTPS servers can now be configured in the hostfingerprints section. That makes it possible to verify the identify of web servers without configuring and trusting the CA chain. Limitations: * Portnumbers are ignored, just like with ordinary certificates. * Host name matching is case sensitive.
-
- Jan 05, 2011
-
-
Martin Geisler authored
-
Martin Geisler authored
-
- Dec 20, 2010
-
-
Zhigang Wang authored
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>
-
- Dec 03, 2010
-
-
Thomas Arendsen Hein authored
-
- Dec 01, 2010
-
-
Martin Geisler authored
-
Martin Geisler authored
-
Nicolas Dumazet authored
In particular, we can ask users to run make RSTARGS='--traceback' doc when we need debugging information
-
- Nov 04, 2010
-
-
Martin Geisler authored
After 0d09991f91ee the hg(1) manpage contains a section with help extracted from the extensions, so we should depend on them too.
-
- Oct 26, 2010
-
-
Dan Villiom Podlaski Christiansen authored
-