- Apr 17, 2013
-
-
Mads Kiilerich authored
Better do it once than see random changes in diffs later.
-
- Apr 14, 2013
-
-
Mads Kiilerich authored
-
- Feb 10, 2013
-
-
Dan Villiom Podlaski Christiansen authored
...for prettier HTML!
-
- Dec 09, 2012
-
-
Mads Kiilerich authored
The check pattern only checked for whitespace between keyword and operator. Now it also warns: > x = f(),7 missing whitespace after , > x = f()+7 missing whitespace in expression
-
- Aug 13, 2012
-
-
Katsunori FUJIWARA authored
This patch adds "doc/check-seclevel.py" which checks below in help documents: - whether unknown or unavailable section marks are used or not - whether appropriate section mark is used at sub-sectioning It should be invoked in "doc" directory. It checks all help documents of Mercurial (topics, commands, extensions), if no file is specified by --file option. With --file option, it checks contents of the specified file as help document, for self testing purpose: -t/-c/-e/-C are used to specify what kind of help document contents of the specified file is. This checking is related to changeset 979b107eaea2.
-
- Aug 17, 2012
- Jul 25, 2012
-
-
Katsunori FUJIWARA authored
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.
-
- May 12, 2012
-
-
Brodie Rao authored
-
Brodie Rao authored
-
- May 08, 2012
-
-
Nikolaj Sjujskij authored
Since docutils 0.9, `roman` module has been moved from module directory root (i.e. `site-packages/roman.py`) to `docutils.utils` module. Therefore `import roman` statement should be wrapped in `try: ... except ImportError: ...` block to handle importing correctly.
-
- Apr 30, 2012
-
-
Martin Geisler authored
I sometimes look at a piece of software and if the man page says "Copyright 2004", then I'm inclined to think that the project is stale or that the authors are lazy. Neither is good publicity for us :-)
-
- 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
-