merge: collect checking for unknown files at end of manifestmerge() The 'c' and 'dc' actions include creating a file on disk and we need to check that no conflicting file exists unless force=True. Move two of the calls to _checkunknownfile() to a single place at the end of manifestmerge(). This removes some of the reading of filelogs from the heart of manifestmerge() and collects it in one place close to where its output (entries in the 'aborts' list) is used. Note that this removes the unnecessary call to _checkunknownfile() when force=True in one of the code paths.

merge: introduce 'c' action like 'g', but with additional safety _checkunknownfile() reads the filelog of the remote side's file. For narrow clones, the filelog will not exist for all files and we need a way to avoid reading them. While it would be easier for the narrow extension to just override _checkunknownfile() and make it ignore files outside the narrow clone, it seems cleaner to have manifestmerge() not care about filelogs (considering its name). In order to move the calls to _checkunknownfile() out, we need to be able to tell in which cases we should check for unknown files. Let's start by introducing a new action distinct from 'g' for this purpose. Specifically, the new action will be just like 'g' except that it will check that for conflicting unknown files first. For now, just add the new action type and convert it to 'g'.

merge: structure 'remote created' code to match table This does duplicate the call to _checkunknownfile(), but it will simplify future patches.

pushkey: run hook after the lock release The pushkey operation used to be in its own wireprotocol command and (in practice) always be lock free when running the hook. With bundle2, it happen in a greater scheme and a hook running locking command would get stuck. We now run such hooks after the lock release as similar hook do. Bundle2 test are altered to ensure we are lockfree at hook running time.

setup: use changes since latest tag instead of just distance For a Mercurial built on the merge from stable into default right after 3.2.2 was released -- 19ebd2f88fc7 -- the version number produced was "3.2.2+4". This is potentially misleading, since in reality the built Mercurial includes many more changes compared to 3.2.2. Change the versioning scheme so that we take into consideration all the changes present in the current revision that aren't present in the latest tag. For 19ebd2f88fc7 the new versioning scheme results in a version number of "3.2.2+256". This gives users a much better idea of how many changes have actually happened since the latest release. Since changessincelatesttag is always greater than or equal to the latesttagdistance, this will produce version numbers that are always greater than or equal to the old scheme. Thus there's minimal compatibility risk.

setup: use changessincelatesttag from archive if present changessincelatesttag gives one a better idea of how much the code has changed since. Since changessincelatesttag is always greater than or equal to the latesttagdistance (see previous patch for why), this will always produce version numbers greater than or equal to the previous scheme.

archive: store number of changes since latest tag as well This is different from latesttagdistance in that while latesttagdistance is defined to be the length of the longest path to the latest tag, changessincelatesttag is the number of changes contained in @ that aren't contained in the latest tag. So, if 't' is the latest tag in the repository below: t | v --o--o----o \ \ ..o..o..@ then latesttagdistance is 2, but changessincelatesttag is 4. Note that changessincelatesttag is always greater than or equal to the latesttagdistance -- that's because changessincelatesttag counts all the changes in the longest path since the latest tag, and possibly others. This is an important fact that we'll take advantage of in upcoming patches.

merge with stable

demandimport: blacklist distutils.msvc9compiler (issue4475) This module depends on _winreg, which is windows-only. Recent versions of setuptools load distutils.msvc9compiler and expect it to ImportError immediately when on non-Windows platforms, so we need to let them do that. This breaks in an especially mystifying way, because setuptools uses vars() on the imported module. We then throw an exception, which vars doesn't pick up on well. For example: In [3]: class wat(object): ...: @property ...: def __dict__(self): ...: assert False ...: In [4]: vars(wat()) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-4-2781ada5ffe6> in <module>() ----> 1 vars(wat()) TypeError: vars() argument must have __dict__ attribute Which is similar to the problem we run into.

largefiles: don't duplicate 'actions' into 'actionbyfile'

merge: make calculateupdates() return file->action dict This simplifies largefiles' overridecalculateupdates(), which no longer has to do the conversion it started doing in 38e55e55ae4d (largefiles: rewrite merge code using dictionary with entry per file, 2014-12-09). To keep this patch small, we'll leave the name 'actionbyfile' in overrides.py. It will be renamed in the next patch.

merge: let _forgetremoved() work on the file->action dict By moving the conversion from the file->action dict after _forgetremoved(), we make that method shorter by removing the need for the confusing 'xactions' variable.

merge: let _resolvetrivial() work on the file->action dict By moving the conversion from the file->action dict after _resolvetrivial(), we greatly simplify and clarify that method.

merge: let bid merge work on the file->action dict By moving the conversion from the file->action dict after the bid merge code, bid merge can be simplified a little. A few tests are affected by this change. Where we used to iterate over the actions first in order of the action type ('g', 'r', etc.) [1], we now iterate in order of filename. This difference affects the order of debug log statements. [1] And then in the non-deterministic order of files in the manifest dictionary (the order returned from manifest.diff()).

merge: write manifestmerge() using dictionary with entry per file In the same vein as 38e55e55ae4d (largefiles: rewrite merge code using dictionary with entry per file, 2014-12-09), rewrite manifestmerge() itself as dictionary with the filename as key. This will let us simplify some of the other code in merge.py and eventually drop the conversion in the largefiles code. No difference in speed could be detected (well within the noise level when run in Mozilla repo).

repoview: backout ced3ecfc2e57 Monkey patching repoview does not really work and making it really work will be really hard. So we better have it broken without complexity than broken with extra complexity.

largefile: explain why no monkey patching on a repoview The comment requested for investigations, here they are.

largefile: backout ca54fb3d71ce The hack for method monkey patching on repoview has been ruled out as fragile, so we are rolling it back. We'll expand the explanation in the next changeset.

incoming: handle phases the same as pull Now that bundlerepo can move phases safely, 'hg incoming' can share its phase handling code with pull to better reflect what would actually show up.

bundlerepo: retract phase boundary This patch makes bundrepo retract the phase boundary for new commits to 'draft' status, which is consistent with the behavior of 'hg unbundle'. The old behavior was for commits to appear with the same phase as their nearest ancestor in the base repository. This affects several classes of operation: * Inspecting a bundle with the -B flag * Treating a bundle file as a peer (old: everything public, new: everything draft) * Incoming command (neither old or new behavior is sensible -- fixed in next patch)

bundlerepo: implement safe phasecache This patch makes bundlerepo use a subclass of phasecache that will allow phase boundaries to be moved around, but will never write them to the underlying repository.

localrepo.__getitem__: add slicing support This allows the python slice syntax to be used with revision numbers when indexing into a repository, such as repo[8:]

ignore: resolve ignore files relative to repo root (issue4473) (BC) Previously these would be considered to be relative to the current working directory. That behavior is both undocumented and doesn't really make sense. There are two reasonable options for how to resolve relative paths: - relative to the repo root - relative to the config file Resolving these files relative to the repo root matches existing behavior with hooks. An earlier discussion about this is available at http://mercurial.markmail.org/thread/tvu7yhzsiywgkjzl. Thanks to Isaac Jurado <diptongo@gmail.com> for the initial patchset that spurred the discussion.

test-hgignore: add testing for ui.ignore I couldn't find any tests for this, and we're going to make changes here in upcoming patches.

tests: add missing globs for Windows I couldn't figure out how to glob the first chunk for Windows, so it's been conditionalized.

share: use the 'sharedpath' attr on repo instead of reloading from the file Seems like a useful optimization, and now the exact file content is not a concern.

share: fix source repo lookup on Windows The stored path contains platform specific separators, so splitting on '/.hg' returned the string unmodified on Windows. The source was then looked for in $source/.hg/.hg, which obviously fails. This caused cascading errors in test-share.t relating to the recent bookmark support.

help: suggest '-v -e' to get built-in aliases for extensions (issue4461) If extension name matches one of command names, suggest user to type 'hg help -v -e <extension>' to get full list of built-in aliases

test-check-commit-hg: clarify misleading "commit message rules" error The test case doesn't only check the commit message, but also the patch, which can result in confusing output like + Revision df6f06d17100 does not comply to commit message rules + ------------------------------------------------------ + 32: adds double empty line + + even when there are no double blank lines in the commit message. Drop the "commit message" part to make it less confusing.

keyword: handle resolve to either parent Merged files are considered modified at commit time even if only 1 parent differs. In this case we must use the change context of this parent for expansion. The issue went unnoticed for long because it is only apparent until the next update to the merge revision - except in test-keyword where it was always staring us in the face.