Mercurial: Changelog

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()'

hgweb: improve colors for comparison page delete: red -> red insert: green -> yellow change: yellow -> gray

histedit: fix new nodes computation with --continue (issue3534) When running the following actions: pick 617f94f13c0f 1 +4 drop 888f9082bf99 2 +5 fold 251d831eeec5 3 +6 if the fold fails, is fixed by the user with a new changeset, --continue will ignore the new revision when generating the fold changelog. This was caused by --continue detecting new changesets as descendants of the parent not descendants of changesets in the initial list. In this case, dropped changesets must be ignored. Even with the computation fixed, the 'newchildren' list was always emptied by the filtering loop and passed empty to finishfold(). Note that changesets dropped and recreated identically will still be missed. This probably cannot be solved but is unlikely to happen. Other things, like 'newchildren' having multiple heads, should be checked as well.