doc: unify section level between help topics 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.

addremove: mention --similarity defaults to 100 (issue3430)

revset: polish explanation of the difference between file() and filelog()

strip: move bookmarks to nearest ancestor rather than '.' If you've got this graph: 0-1-2 \ 3 and 3 is checked out, 2 is bookmarked with "broken", and you do "hg strip 2", the bookmark will move to 3, not 1. That's always struck me as a bug. This change makes bookmarks move to the tipmost ancestor of the stripped set rather than the currently-checked-out revision, which is what I always expected should happen.

largefiles: fix exception hack for i18n (issue3197) Properly fixing this is quite a bit trickier.

merge with crew

webcommands: do not modify repo.tagslist() Repeatedly refreshing a gitweb summary page served by hg serve would show the tags list switching between two different sequences.

tag: don't allow tagging the null revision (issue1915) Also fixed the tests that were doing this and expected it to work

i18n: add/relocate "i18n keyword" comments for i18n messages in revset.py

revset: use appropriate predicate name in error messages "extinct" and "unstable" predicates use "obsolete" implementation internally, but own predicate name should be used in error messages of them instead of "obsolete".

test-histedit-fold: fix for Windows Fixes 336121088ef1 failing with MSYS. MSYS sh.exe mangled that path by applying its path magic, which caused the test to fail on Windows.

tags: visit new heads in forward order when rebuilding cache This improves performance of building the tag cache by 4x on a repo with ~2800 heads.

identity: show trailing '+' for dirty subrepos (issue2839)

discovery: fix invalid comment about extinct being ignored

obsolete: fix decoding error message arguments

push: do not try to push remote obsolete if local has none

help: fix some instances of 'the the'

pager: work around bug in python 2.4's subprocess module (issue3533) hg v2.2.2 fixed the pager on Windows, but broke it on Python 2.4. This patch only uses the new behavior if Python >= 2.5 is detected.

clone: copy obsolete markers during local clone This change adds `obsstore` to the list of files copied by local clone, until now changesets were copied without their obsolete markers. Note: extinct changesets were and are still included by such clones to enable hardlinking. There is no obvious reason to prevent their exchange here. Rebased by Patrick Mezard <patrick@mezard.eu>

discovery: add extinct changesets to outgoing.excluded Before this change, push would incorrectly fast-path the bundle generation when extinct changesets are involved, because they are not added to outgoing.excluded. The reason to do so are related to outgoing.excluded being assumed to contain only secret changesets by scmutil.nochangesfound(), when displaying warnings like: changes found (ignored 9 secret changesets) Still, outgoing.excluded seems like a good API to report the extinct changesets instead of dedicated code and nothing in the docstring indicates it to be bound to secret changesets. This patch adds extinct changesets to outgoing.excluded and fixes scmutil.nochangesfound() to filter the excluded node list. Original version and test by Pierre-Yves.David@ens-lyon.org

convert/svn: handle non-local svn destination paths (issue3142) test-convert-svn-sink.t still pass and I tested pushing to an svn+ssh repository

setup: fix build_hgexe for mingw32 compiler Fixes python setup.py build_hgexe -i --compiler=mingw32

largefiles: fix path handling for cp/mv (issue3516) Previously, a copy or a move of a largefile only worked if the cwd was the root of the repository. The first issue was that the destination path passed to os.mkdirs() chopped the absolute path to the standin after '.hglf/', which essentially created a path relative to the repository root. Similarly, the second issue was that the source and dest paths for copyfile() were relative to the repo root. This converts these three paths to absolute paths. Some notable issues, regardless of the directory in which the cp/mv is executed: 1) The copy is not being recorded in lfdirstate, but it is in dirstate for the standins. I'm not sure if this is by design (i.e. minimal info in lfdirstate). 2) status -C doesn't behave as expected. Using the testcase as an example: # after mv + ci $ hg status -C -v --rev '.^' # expected to see 'A' and ' ' lines too R dira\dirb\largefile $ hg status -C -v --rev '.^' foo/largefile # no output # expected to see 'A' and ' ' lines only $ hg status -C -v --rev '.^' foo/ # no output # expected to see 'A', ' ' and 'R' lines $ hg status -C -v --rev '.^' ./ # expected to see 'A' and ' ' lines too R dirb\largefile $ hg status -C -v --rev '.^' ../.hglf/dira/foo/largefile A ..\.hglf\dira\foo\largefile ..\.hglf\dira\dirb\largefile # no 'R' expected when new file is specified $ hg status -C -v --rev '.^' ../.hglf # OK A ..\.hglf\dira\foo\largefile ..\.hglf\dira\dirb\largefile R ..\.hglf\dira\dirb\largefile

revset: add explanation about difference between 'filelog()' and 'file()'