merge: indent to prepare for next patch

merge with stable

factotum: convert Plan 9 quoted string to Python string

plan9: setup check for current python build

add: check for the existence of a file matched inexactly before adding it The change in 10697f29af2b created a problem on Windows and OS X: --- /usr/local/mercurial/tests/test-issue660.t +++ /usr/local/mercurial/tests/test-issue660.t.err @@ -47,6 +47,8 @@ Should succeed - shadow removed: $ hg add b + adding b/b + b/b does not exist! Prior to the failing 'hg add', the file 'b/b' was added and committed, then 'b' was recursively deleted from the filesystem, file 'b' was created and the delete was recorded with 'hg rm --after'. This add is attempting to record the existence of file 'b'. A filesystem that is not case sensitive prevents dirstate.walk() from skipping its step 3, and step 3 has the effect of inserting removed files into the walk list. The Linux code doesn't run through step 3, and didn't exhibit the problem. It's not clear why a non case sensitive filesystem triggers step 3, given that the path normalization occurs in step 2. Prior to 10697f29af2b, part of the check here was 'f not in repo.dirstate' instead of 'f not in wctx'. Files in the 'r' state are filtered out of context.__contains__() but not dirstate.__contains__(). Therefore the removed file name wasn't added to the list of files to add when checking against dirstate. That change was to allow removed files to be readded, but adding a file that doesn't exist is nonsensical. If the user specifies a missing file, it will be an exact match and will still fail.

tests: choose the proper environment variable style for the platform Windows was printing out 'commit $HG_NODE' instead of the actual hash.

tests: fix another multi-statement hook for Windows The double quotes are necessary, otherwise it tries to pipe into a program named 'short'. An '&' could serve as a command separator on Windows instead of ';', but I don't see any obvious way to swap these depending on the platform. In this case though, there really wasn't a need for multiple statements.

run-tests: set a default largefiles usercache in the default hgrc file This fixes a test failure introduced in 4be754832829 on Windows and OS X, where the cached largefile wasn't being deleted because the named .cache directory didn't exist. It only existed on Linux because the test suite sets $HOME to the directory of the test being run, and Linux uses $HOME/.cache by default. Most of the other largefiles tests explicitly set this value at the top of their scripts, but test-largefiles-update.t didn't pick that up when it was created. Those scripts that do set a value will override this. We could just set the parameter in the test-largefiles-update.t script, but there are a few other non obvious tests that exercise largefiles too. These largefiles end up being cached in the user's real cache, so proper hygiene dictates that this not be left to each individual test script.

merge: remove obsolete check for untracked files in 'dm' action Since 0776a6cababe (merge: don't use unknown(), 2012-02-09), untracked files are no longer included in the manifest diff, so there is no need to check exclude them when renaming files for directory moves with the 'dm' action.

merge: remove dead assignment in applyupdates()

merge: move calculateupdates() before applyupdated() calculateupdates() happens before applyupdates(), so move it before in the code. That also moves it close to manifestmerge(), which is a good location as calculateupdates() is the only caller of manifestmerge().

merge: remove unused variables from _checkcollision()

largefiles: avoid exec-bit examination on the platform being unaware of it Changeset 24600c9d7f4e introduced the examination of exec bit of largefiles in "hg status --rev REV" case, but it doesn't avoid it on the platform being unaware of exec-bit (e.g. on NTFS of Windows).

merge with stable

changegroup: fix file linkrevs during reorders (issue4462) Previously, if reorder was true during the creation of a changegroup bundle, it was possible that the manifest and filelogs would be reordered such that the resulting bundle filelog had a linkrev that pointed to a commit that was not the earliest instance of the filelog revision. For example: With commits: 0<-1<---3<-4 \ / --2<--- if 2 and 3 added the same version of a file, if the manifests of 2 and 3 have their order reversed, but the changelog did not, it could produce a filelog with linkrevs 0<-3 instead of 0<-2, which meant if commit 3 was stripped, it would delete that file data from the repository and commit 2 would be corrupt (as would any future pulls that tried to build upon that version of the file). The fix is to make the linkrev fixup smarter. Previously it considered the first manifest that added a file to be the first commit that added that file, which is not true. Now, for every file revision we add to the bundle we make sure we attach it to the earliest applicable linkrev.

merge: consistently use single quotes for non-user-facing strings Because I'm getting tired of searching for both 'O' and "O".

localrepo: add a currenttransaction method This method returnx the current transaction or None: it will allow a cache writer to hook in an existing transaction.

repoview: extract actual hidden cache writing in its own function This will allow the generation of this cache within the transaction. Relying on the transaction will reduce the chance of reader seeing bad cache.

templates: fix broken "less" & "more" links in paper style (issue4460) "/search", which is an invalid command in hgweb, was mistakenly used for "[show] more [revsets]" and "[show] less [revsets]" links on search page in templates "paper" (and those which inherit paper, such as coal) before and worked fine until 6e1fbcb18a75, which made hgweb more strict about invalid commands.

push: stop independent usage of bundle2 in syncphase (issue4454) The phase-syncing code was using bundle2 if the remote supported it. It was doing so without regard to bundle2 activation on the client. Moreover, the phase push is now properly included in the unified bundle2 push, so having extra code in syncphase should be useless. If the remote is bundle2-enabled, the phases should already be synced. The buggy verification code was leading to a crash when a 3.2 client was pushing to a 3.1 server. The real bundle2 path detected that their versions were incompatible, but the syncphase code failed to, sending an incompatible bundle2 to the server. We drop the useless and buggy code as a result. The "else" clause is de-indented in the process.

dirstate: speed up repeated missing directory checks In a mozilla repo with tip at bb3ff09f52fe, hg update tip~1000 && time hg revert -nq -r tip . displays ~4:20 minutes. With tip~100, it runs in ~11 s. With revision 100000, it did not finish in 12 minutes. Revert calls dirstate.status() with a matcher that matches each file in the target revision. The main problem [1] lies in dirstate._walkexplicit(), which looks for matching deleted directories by checking whether each path is prefix of any path in the dirstate. With m files in the dirstate and n files in the target revision that are not in the dirstate, this is clearly O(m*n). Let's improve by keeping a lazily initialized set of all the directories in the dirstate, so the time becomes O(m+n). After this patch, the 4:20 minutes become 5.5 s, while for a single missing path, it slows down from 1.092 s to 1.150 s (best of 4). The >12 min case becomes 5.8 s. [1] A narrower optimization would be to make revert take the fast path for '.' and '--all'.

revert: access status fields by name rather than index For better readability.

subrepo: remove "_getstorehashcachepath" referred by no other code paths

subrepo: replace direct file APIs around "writelines" by "vfs.writelines" This patch also replaces "self._getstorehashcachepath" (building absolute path up) by "self._getstorehashcachename" (building relative path up), because "vfs.writelines" requires relative path.

vfs: add "writelines" This patch allows "writelines" to take "mode" and "notindexed" arguments, because subsequent patch for subrepo requires both.

vfs: add "notindexed" argument to invoke "ensuredir" with it in write mode This patch uses "False" as default value of "notindexed" argument, even though "vfs.makedir()" uses "True" for it, because "os.mkdir()" doesn't set "_FILE_ATTRIBUTE_NOT_CONTENT_INDEXED" attribute to newly created directories.

subrepo: replace direct file APIs around "readlines" by "vfs.tryreadlines" This patch also replaces "self._getstorehashcachepath" (building absolute path up) by "self._getstorehashcachename" (building relative path up), because "vfs.tryreadlines" requires relative path. This patch makes "_readstorehashcache()" return "[]" (returned by "vfs.tryreadlines()"), when cache file doesn't exist, even though "_readstorehashcache()" returned '' (empty string) in such case before this patch. "_readstorehashcache()" is invoked only by the code path below in "_storeclean()": for filehash in self._readstorehashcache(path): if filehash != itercache.next(): clean = False break In this case, "[]" and '' don't differ from each other, because both of them cause avoiding iteration of "for loop".

vfs: add "readlines" and "tryreadlines" This patch allows "readlines" and "tryreadlines" to take "mode" argument, because "subrepo" requires to read files not in "rb" (binary, default for vfs) but in "r" (text) mode in subsequent patch.

subrepo: add "_cachestorehashvfs" to handle cache store hash files via vfs This "vfs" object will be used by subsequent patches to handle cache store hash files without direct file APIs. This patch decorates "_cachestorehashvfs" with "@propertycache" to delay vfs creation, because it is used only for cooperation with other repositories. In this patch, "/" is used as the path separator, even though "self._repo.join" uses platform specific path separator (e.g. "\\" on Windows). But it is reasonable enough, because "store" and other management file handling already include such implementation, and they work well.

subrepo: remove "_calcfilehash" referred by no other code paths

subrepo: replace "_calcfilehash" invocation by "vfs.tryread" "_calcfilehash" can be completely replaced by simple "vfs.tryread" invocation. def _calcfilehash(filename): data = '' if os.path.exists(filename): fd = open(filename, 'rb') data = fd.read() fd.close() return util.sha1(data).hexdigest() Building absolute path "absname" up by "self._repo.join" for files in "filelist" is avoided, because "vfs.tryread" does so internally.

subrepo: replace "os.path.exists" by "exists" via wvfs of the parent Existance of specified "path" should be examined by "exists" via wvfs of the parent repository, because the working directory of the parent repository may be in UTF-8 mode. Wide API should be used via wvfs in such case. In this patch, "/" is used as the path separator, even though "path" uses platform specific path separator (e.g. "\\" on Windows). But it is reasonable enough, because "store" and other management file handling already include such implementation, and they work well.

subrepo: avoid redundant "util.makedirs" invocation "util.makedirs" for the (sub-)repository root of "hgsubrepo" is also executed in the constructor of "localrepository", if "create" is True and ".hg" of it doesn't exist. This patch avoids redundant "util.makedirs" invocation in the constructor of "hgsubrepo".

merge: remove confusing comment about --force manifestmerge() has a piece of code that's roughly: if not force and different: abort else: # if different: old untracked f may be overwritten and lost ... The comment only talks about what happens when 'different' is true, and in combination with the if-block above, that must mean that it is only about what happens when 'force and different'. It seems quite fine that files are overwritten when 'force' is true, so let's remove the comment. As it stands, it can easily be interpreted as a TODO (which is how I interpreted it at first).

phases: read pending data when appropriate If we are called by a hook and pending data exists, read those.

bookmark: read pending data when appropriate If we are called by a hook and pending data exists, read it.

test-bundle2: check visible data in pre/post-transaction hooks We are about to make bookmarks and phases available for hooks. Therefore we need a witness for this new availability. We introduce the new hooks in a distinct changeset to reduce the noise in the ones with actual changes.

transaction: write pending generated files Such file are generated with a .pending prefix. It is up to the reader to implement the necessary logic for reading pending files. We add a test to ensure pending files are properly cleaned-up in both success and error cases.

transaction: have _generatefile return a boolean The function returns True if any files were generated. This will be used to know if any pending files have been written.

transaction: allow generating files with a suffix This will allow us to generate temporary pending files. Files generated with a suffix are assumed temporary and will be cleaned up at the end of the transaction.

transaction: fix some docstring grammar

transaction: accept a 'location' argument for registertmp This will allow generation of temporary files outside of store. This will be useful for bookmarks.

tests: handle differences between missing file error strings on Windows and Unix

run-tests: don't warn on unnecessary globs mandated by check-code.py When test output is processed, if os.altsep is defined (i.e. on Windows), TTest.globmatch() will cause a warning later on if a line has a glob that isn't necessary. Unfortunately, the regex checking in check-code.py doesn't have this context. Therefore we ended up with cases where the test would get flagged with a warning only on Windows because a glob was present, because check-code.py would warn if it wasn't. For example, from test-subrepo.t: $ hg -R issue1852a push `pwd`/issue1852c pushing to $TESTTMP/issue1852c (glob) The glob isn't necessary here because the slash is shown as it was provided. However, check-code mandates one to handle the case where the default path has backslashes in it. Break the cycle by checking against a subset of the check-code rules before flagging the test with a warning, and ignore the superfluous glob if it matches a rule. This change fixes warnings in test-largefiles-update.t, test-subrepo.t, test-tag.t, and test-rename-dir-merge.t on Windows. I really hate that the rules are copy/pasted here (minus the leading two spaces) because it would be nice to only update the rules once, in a single place. But I'm not sure how else to do it. I'm open to suggestions. Splitting some of the rules out of check-code.py seems wrong, but so does moving check-code.py out of contrib, given that other checking scripts live there. There are other glob patterns that could be copied over, but this is enough to make the current tests run on Windows.

update: remove unnecessary check for unknown files with --check As far as I and the test suite can tell, the checks in manifestmerge() already report the errors (whether or not --check is given), so we don't need to call merge.checkunknown(). Since this is the last call to the method, also remove the method.

merge with stable

tests: move a multi-statement debuglocks hook into a shell script for Windows Before this patch, a part of "test-push-hook-lock.t" fails unexpectedly on Windows environment, because semicolon (";") isn't recognized as the command separator by "cmd.exe". This is fixed the same way as a similar issue in 7c253c23de3b.

tests: fix globs for Windows test-largefiles-update.t, test-subrepo.t, test-tag.t, and test-rename-dir-merge.t still warn about no result returned because of unnecessary globs that test-check-code-hg.t wants, relating to output for pushing to, pulling from and moving X to Y.

run-tests: include quotes in the HGEDITOR value when storing sys.executable This fixes test-install.t on Windows that broke in 2122b82b6987 when shlex.split() was added to the debuginstall command: @@ -7,8 +7,11 @@ checking installed modules (*mercurial)... (glob) checking templates (*mercurial?templates)... (glob) checking commit editor... + Can't find editor 'c:\Python27\python.exe -c "(omitted)"' in PATH + (specify a commit editor in your configuration file) checking username... - no problems detected + 1 problems detected, please check your install! + [1] What happens is that shlex.split() on Windows turns this: c:\Python27\python.exe -c "import sys; sys.exit(0)" into this: ['c:Python27python.exe', '-c', 'import sys; sys.exit(0)'] While technically a regression, most programs on Windows live in some flavor of 'Program Files', and therefore the environment variable needs to contain quotes anyway to handle the space. This wasn't handled prior to the shlex() change, because it tested the whole environment variable to see if it was an executable, or split on the first space and tested again.

mq: when adding headers in plain mode, separate them from message (issue4453) c87f2a5a6e49 did a clean-up in one direction ... but we want it in the other direction.

mq: introduce insertplainheader - same naive implementation as before

mq: when setting message in plain mode, separate it from header (issue4453) Fix inconsistent handling of plain header separation in mq patcheader - and contrary to c87f2a5a6e49, do it in the direction of having an empty line between header and description. Plain patches are like mails and should thus have an empty line between headers and body in compliance with RFC 822 3.1.

setdiscovery: avoid a full changelog graph traversal We were definitely being suboptimal here: we were constructing two full sets, one with the full set of common nodes (i.e. a graph traversal) and one with all nodes. Then we subtract one set from the other. This whole process is O(commits) and causes discovery to be significantly slower than it should be. Instead, keep track of common incrementally and keep undecided as small as possible. This makes discovery massively faster on large repos: on one such repo, 'hg debugdiscovery' over SSH with one commit missing on the client and five on the server went from 4.5 seconds to 1.5. (An 'hg debugdiscovery' with no commits missing on the client, i.e. connection startup time, was 1.2 seconds.)

ancestor: add a way to remove ancestors of bases from a given set This and missingancestors can share state, which will turn out to be perfect for set discovery.

ancestor: add a way to add to bases of a missing ancestor object This will be useful for setdiscovery, since with that we incrementally add to our knowledge of common nodes.

ancestor: add a way to test whether a missing ancestor object has bases This is pretty trivial so there's no unit test coverage for it. This will be used by setdiscovery.

ancestor: remove now-unused missingancestors function Callers should use revlog.incrementalmissingrevs instead.

revlog: switch findmissing* methods to incrementalmissingrevs This will allow us to remove ancestor.missingancestors in an upcoming patch.

revlog: add a method to get missing revs incrementally This will turn out to be useful for discovery.

test-ancestor: add support for multiple tests against one incremental object In upcoming patches we'll add more operations to the object, and this prepares for testing those operations.

test-ancestor: move naive missing ancestor algorithm into a class This mirrors the change to the real missing ancestor algorithm in a previous patch.

ancestor.missingancestors: turn into a state-keeping class This allows multiple efficient missing ancestor queries against the same set of bases. In upcoming patches we'll also define ways to grow the set of bases. The fact that the test output hasn't changed establishes this patch's correctness.

ancestor.missingancestors: calculate start point after filtering revsvisit Any revs that are filtered out are also in basesvisit, which means they wouldn't be returned in the missing list anyway. There's no need to explore such revs or their ancestors. The 'if not revsvisit' check moves down because we can't call max() on an empty set.

ancestor.missingancestors: don't discard from basesvisit We only actually care about whether revsvisit is empty, so we can let basesvisit grow to arbitrary size. It turns out that this actually helps performance. For a large repo with hundreds of thousands of commits, hg perfrevset 'only(0, tip)' (basically the worst case, involving a full DAG traversal) goes from 1.63 seconds to 1.50. hg perfrevset 'only(tip, 0)' remains unchanged at 1.98 seconds.

test-ancestor: use random testing for missing ancestors We're going to make changes to the missing ancestor algorithm, and random testing will give us much more confidence than a fixed set of tests.

test-ancestor: define a main function We're going to add to it in upcoming patches.

test-ancestor: test iteration for lazyancestors This has some test coverage in test-revlog-ancestry.py, but not very much.

ancestor.lazyancestors: take parentrevs function rather than changelog Principle of least privilege, and it also brings this in line with missingancestors.

remove: avoid a bogus warning about no tracked files when removing '.' Previously, any files relative to the root of the repo that match the -I patterns would be deleted, but the command exited with 1 after printing a warning: $ hg remove -S -I 're:.*.txt' . removing sub1/sub2/folder/test.txt removing sub1/sub2/test.txt not removing .: no tracked files

remove: support remove with explicit paths in subrepos

remove: recurse into subrepositories with --subrepos/-S flag Like 'forget', git and svn subrepos are currently not supported. Unfortunately the name 'remove' is already used in the subrepo classes, so we break the convention of naming the subrepo function after the command.

cmdserver: protect pipe server streams against corruption caused by direct io Because pipe-mode server uses stdio as IPC channel, other modules should not touch stdio directly and use ui instead. However, this strategy is brittle because several Python functions read and write stdio implicitly. print 'hello' # should use ui.write() # => ch = 'h', size = 1701604463 'ello', data = '\n' This patch adds protection for such mistakes. Both stdio files and low-level file descriptors are redirected to /dev/null while command server uses them.

cmdserver: postpone creation of pipe server until run() This makes it easy to swap file descriptors while running command server.

cmdserver: use given streams as pipe channels like other commands Because commandserver itself is an hg subcommand, it shouldn't use stdio directly in principle.

revset.only: use cl.findmissingrevs ancestor.missingancestors is really an implementation detail.

manifestmerge: use already existing fl2 synonym for m2.flags(f) Probably not a noticeable performance gain, but shortens the code slightly.

merge: drop underscore prefix from _checkunknown() The method has been called from commands.py since 3eab42088be4 (update: just merge unknown file collisions, 2012-02-09), so drop the underscore prefix that suggests that it's private.

transaction: drop special handling for phases and bookmarks generation We are still doing double backups, but now that we have proper location handling this is less of an issue. Dropping this simplifies the code before we add some pending-related logic. This also ensures we actually test the new 'location' mechanism.

transaction: use 'location' instead of 'vfs' objects for file generation The argument is now a location name. The location must be present in the 'vfsmap' provided to the transaction at creation time.

transaction: use 'location' instead of 'vfs' in the addbackup method This unlock the backup of file outside of store (eg: bookmarks).

addbackup: handle file in subdirectory The current naming scheme ('journal.backups.<file>') resulted is bad directory name when 'file' was in a subdirectory. We now extract the directory name and create the backupfile within it. We plan to use file in a subdirectory for cachefile.

addbackup: use the vfs for the backup destination too The backup file location was always computed using the opener, bypassing the 'location' setting. (And making the feature broken.)

transaction: set backupentries version to proper value Now that all mechanisms are in place, we can advertise it with a proper new version.

transaction: support cache file in backupentries We do not want to abort if anything wrong happen while handling a cache file. Cache file have way to be invalidated and if old/bad version stay no misbehavior will happen. Proper value will eventually be computed and the wrong will be righten. This changeset use the transaction reporter (usually writing on stderr) to write details about failed cache handling. This will only apply to write operation using a transaction. The usual update during read only operation will stay a debug message. I was on the way to bring these message back to debug level when I realised it could be a feature. People with write access to the repository are likely to have the power to fix error related to cache (and it is valuable to fix them). So let the things as is for now.

transaction: use the location value when doing backup We finally use the 'location' value coupled with the 'vfsmap' to restore backup for the right file.

transaction: pass a vfs map to the transaction The goal is to allow access to file outside ofthe store directory from the transaction. The obvious target are the `bookmarks` file. But we can envision usage for cache too. We keep passing a main opener explicitly because a lot of code rely on this default opener. The main opener (operating on store) is using an empty key ''.

transaction: change the on disk format for backupentries We need to store new data to improve the current transaction logic: - location: We want to generate and backup file outside of the 'store' (eg: bookmarks, or various cache files). This requires knowing and preserving where each file is located. The value of this new field is a string. It will be used as a key for a vfs mapping. - cache: We would like to handle cache file in the transaction code. This Will help to have cache consistent with the repository state and avoid performance issue on big repository like Mozilla. However, failure to handle cache file should not result in a transaction failure. We add a new field that carry this information. The value is boolean, A True value mean any error while handling this file can be ignored. Those two mechanisms are not implemented yet, but they are now persisted in the on disk file. Support for new mechanisms is coming in later changeset. We update the file format now and will introduce the new features in later changeset. The format version is set to 0 until we actually support the new feature. This will prevent misunderstanding between incomplete and final client. Support for reading both version 1 and (future) version 2 could be achieved (using default value when reading version 1) but has not been seen as necessary for now.

silenttestrunner: add environment variable to make tests noisy again As I've been working on complicated extension code it's been handy to be able to get standard unittest verbose output so I can find crashers more efficiently.

largefiles: update comments to refer to the right overridden method This cleans up leftovers from b228ad1f79d7 (largefiles: override calculateupdates instead of manifestmerge, 2014-03-02).

revlog: cache chain info after calculating it for a rev (issue4452) This dumb cache works surprisingly well: on a repository with typical delta chains ~50k in length, unbundling a linear series of 5000 revisions (changelogs and manifests only) went from 60 seconds to 3.

manifest: add matches() method Move the code in context._manifestmatches() into a new manifest.matches(). It's a natural place for the code to live and it allows other callers to easily use it. It should also make it easier to optimize the new method in alternative implementations of the manifest (same reasoning as with manifest.diff()).

context.status: pass status tuple into _buildstatus By passing a status tuple (instead of the current list), we can access the status fields by name and make it a little more readable.

context.status: avoid de- and reconstructing status tuple We can just modify the status tuple we got from dirstate.status() instead of deconstructing it and constructing a new instance, thereby simplifying the code a little.

context.status: make _dirstatestatus() return an status tuple Letting _dirstatestatus() return an scmutil.status instance also means that _buildstatus() will always return such an instance, so we can remove the conversion from the call sites.

context.status: wipe deleted/unknown/ignored fields when reversed It makes no sense to request reverse status (i.e. changes from the working copy to its parent) and then look at the deleted, unknown or ignored fields. If you do, you would get the result from the forward status (changes from parent to the working copy). Instead of giving a nonsensical answer to a nonsensical question, it seems a little saner to return empty lists. It might be best if we could prevent the caller accessing these lists, but it's doubtful it's worth the trouble.

patch.trydiff: add support for noprefix

mdiff.unidiff: add support for noprefix

diff: add a --noprefix option See previous patch descriptions for the motivation. The tests reflect the current state of the world -- as we add support we'll see changes in the test output.

patch.diffopts: add support for noprefix In an upcoming patch we'll enable support as an option to 'hg diff' as well. The tests reflect the current state of the world -- as we add support we'll see changes in the test output.

patch.diffopts: allow a setting to be forced in plain mode Upcoming patches will add an option that will almost certainly break diff output parsers when enabled. Add support for forcing an option to something in plain mode, as a fallback. Options passed in via the CLI are not affected, though -- it is assumed that any script passing the option in explicitly knows what it is doing.

patch.diffopts: break get function into if statements We're going to add another condition here, and with the current structure that becomes just too confusing.

mdiff.diffopts: add a new noprefix option By popular demand, we introduce an option to disable the 'a/' and 'b/' prefixes in diff output. This makes copying and pasting filenames from diff output easier. This option will be implemented and documented in upcoming patches. To ensure that existing scripts that parse output don't break, we will ensure that this prefix is disabled in plain mode. A straight 'hg export | hg import' without HGPLAIN=1 will still be broken though, but there's little that can be done about that.

mdiff.diffopts: add doc comment for nobinary

changelog: register changelog.i.a as a temporary file The file is registered to make sure the transaction is cleaned up in all cases.

transaction: allow registering a temporary transaction file During the transaction, files may be created to store or expose data involved in the transaction (eg: changelog index data are written in a 'changelog.i.a' for hooks). But we do not have an official way to record such file creation and make sure they are cleaned up. The lack of clean-up is currently okay because there is a single file involved and a single producer/consumer. However, as we want to expose more data (bookmarks, phases, obsmarker) we need something more solid. The 'backupentries' mechanism could handle that. Temporary files can be encoded as a backup of nothing '('', <temporarypath>)'. We "need" to attach it to the same mechanism as we use to be able to use temporary transaction files outside of .'store/' and 'backupentries' is expected to gain such feature. This changeset makes it clear that we should rename 'backupentries' to something more generic.

transaction: always generate file on close The conditionnal was buggy and file were only generated if "onclose" was defined. By luck, "onclose" was always defined.

remove: move most of the implementation into cmdutils.remove() This will allow access to the reusable parts from subrepos, similar to add(), forget(), etc.

revlog: increase I/O bound to 4x the amount of data consumed This doesn't affect normal clones since they'd be bound by the CPU bound below anyway -- it does, however, improve generaldelta clones significantly. This also results in better deltaing for generaldelta clones -- in generaldelta clones, we calculate deltas with respect to the closest base if it has a higher revision number than either parent. If the base is on a significantly different branch, this can result in pointlessly massive deltas. This reduces the number of bases and hence the number of bad deltas. Empirically, for a highly branchy repository, this resulted in an improvement of around 15% to manifest size.

revlog: bound based on the length of the compressed deltas This is only relevant for generaldelta clones.

revlog: compute length of compressed deltas along with chain length In upcoming patches to the revlog, we're going to split up the notions of bounding I/O and bounding CPU.

revlog: store fulltext when compressed delta is bigger than it This is a very silly case and not particularly likely to happen in the wild, but it turns out we can hit it in a couple of places. As we tune the storage parameters we're likely to hit more such cases. The affected test cases all have smaller revlogs now.

revlog: make a predicate clearer with parens

transaction: extract backupentry registration in a dedicated function We are about to use the 'backupentry' mechanism to allow cleaning up transaction-related temporary files (such as 'changelog.i.a'). We start by extracting the entry registration into its own method for easy reuse. At that point, I would like to rename the backup-file related variable to something generic but I'm a bit short of ideas.

transaction: pass the transaction to 'postclose' callback This mirrors the API for 'pending' and 'finalize' callbacks. I do not have immediate usage planned for it, but I'm sure some callback will be happy to access transaction related data.

transaction: pass the transaction to 'finalize' callback The callback will likely need to perform some operation related to the transaction (eg: registering file update). So we better pass the current transaction as the callback argument. Otherwise callback that needs it has to rely on horrible weak reference trick. This allow already allow us to slay a wild weak reference usage.

transaction: pass the transaction to 'pending' callback The callback will likely need to perform some operation related to the transaction (eg: backing files up). So we better pass the current transaction as the callback argument. Otherwise callback that needs it has to rely on horrible weak reference trick. The first foreseen user of this is changelog._writepending. We would like it to register the temporary file it create for cleanup purpose.

transaction: gather backupjournal logic together in the __init__ The initialisation of file-backup related variable were a bit scattered, we gather them together.

transaction: handle missing file in backupentries (instead of using entries) The case where a backup of a missing file was requested was previously handled by the 'entries' list. As the 'backupentries' is about to gain ability to backup files outside of '.hg/store', we want it to be able to handle the missing file too. Reminder: using 'addbackup' on a missing file means that such file needs to be deleted if we rollback the transaction.

test-hup: use ls instead of echo Having one file entry per line makes it easier to analyse diffs.

largefiles: move "copyalltostore" invocation into "markcommitted" Before this patch, while "hg convert", largefiles avoids copying largefiles in the working directory into the store area by combination of setting "repo._isconverting" in "mercurialsink{before|after}" and checking it in "copytostoreabsolute". This avoiding is needed while "hg convert", because converting doesn't update largefiles in the working directory. But this implementation is not efficient, because: - invocation in "markcommitted" can easily ensure updating largefiles in the working directory "markcommitted" is invoked only when new revision is committed via "commit" of "localrepository" (= with files in the working directory). On the other hand, "commitctx" may be invoked directly for in-memory committing. - committing without updating the working directory (e.g. "import --bypass") also needs this kind of avoiding For efficiency of this kind of avoiding, this patch does: - move "copyalltostore" invocation into "markcommitted" - remove meaningless procedures below: - hooking "mercurialsink{before|after}" to (un)set "repo._isconverting" - checking "repo._isconverting" in "copytostoreabsolute" This patch invokes "copyalltostore" also in "_commitcontext", because "_commitcontext" expects that largefiles in the working directory are copied into store area after "commitctx". In this case, the working directory is used as a kind of temporary area to write largefiles out, even though converted revisions are committed via "commitctx" (without updating normal files).

largefiles: avoid printing messages while transplanting by "_lfstatuswriters" Putting "lambda *msg, **opts: None" (= avoid printing messages always) into "_lfstatuswriters" while transplanting makes explicit passing "printmessage = False" for "updatelfiles()" useless. This patch also removes setting/unsetting "repo._istransplanting" in "overridetransplant", because there is no code path referring it.

largefiles: update standins only at the 1st commit of "transplant --continue" Before this patch, "hg transplant --continue" may record incorrect standins, because largefiles extension always avoid updating standins while transplanting, even though largefiles in the working directory may be modified manually at the 1st commit of "hg transplant --continue". But, on the other hand, updating standins should be avoided at subsequent commits for efficiency reason. To update standins only at the 1st commit of "hg transplant --continue", this patch uses "automatedcommithook", which updates standins by "lfutil.updatestandinsbymatch()" only at the 1st commit of resuming. Even after this patch, "repo._istransplanting = True" is still needed to avoid some status report while updating largefiles in "lfcommands.updatelfiles()". This is reason why this patch omits not "repo._istransplanting = True" in "overriderebase" but examination of "getattr(repo, "_istransplanting", False)" in "updatestandinsbymatch".

largefiles: avoid redundant "updatelfiles" invocation in "overridetransplant" At "hg transplant --merge REV", largefiles newly coming from the 2nd parent (= REV) are marked as "a"(dded) by "patch.patch()", and have to be marked as "n"(ormal) after commit. But until changeset 3100d1cbce32, such largefiles were still marked as "a" unexpectedly even after commit, because no additional entry is added to filelog of such largefiles and they aren't listed in "repo[newnode].files()" in this case: "newnode" is one of newly committed changeset (= result of "repo.commit()"). "updatelfiles" invocation in "overridetransplant" shadows this problem by forcibly synchronizing lfdirstate to dirstate. Now, "updatelfiles" invocation in "overridetransplant" is redundant, because changeset 3100d1cbce32 made "markcommitted" use "ctx.files()" to get targets of "synclfdirstate" instead of "repo[newnode].files()".

merge with stable

util.system: remove unused handling of onerr=ui In our code, onerr is None or util.Abort. It smells bad to overload ui and exception class.

util.system: use ui.system() in place of optional ui.fout parameter

ui: introduce util.system() wrapper to make sure ui.fout is used This change is intended to avoid future problem of data corruption under command server. out=ui.fout is mandatory as long as command server uses stdout as IPC channel.

hook: remove redundant code to redirect http hook output to client stream out=ui and out=ui.fout should be the same here. ui.fout was introduced at afccc64eea73, which was not available when out=ui was added at c37f35d7f2f5.

hgk: forward command output to ui.fout consistently Nobody would want to run hgk in command server, but it should work in principle. This fixes possible data corruption of command-server channel.

merge with stable

Added signature for changeset 643c58303fb0

Added tag 3.2.1 for changeset 643c58303fb0

run-tests: use a try/except ladder instead of looking for a specific version This ensures we get json instead of simplejson in as many places as possible.

hghave: use a less brittle have-json check

sortdict: add insert method Future patches will allow extensions to choose which order a namespace should output in the log, so we add a way for sortdict to insert to a specific location.

sortdict: add iteritems method Future patches will start using sortdict for log operations where order is important. Adding iteritems removes the headache of having to remember to use items() if the object is a sortdict.

addremove: add back forgotten files (BC) After running "hg forget README && hg addremove", README will still be reported as removed, while "hg forget README && hg add README" adds it back so it gets reported as clean. It seems like they should behave the same. Furthermore, it seems like no files should remain untracked after 'hg addremove && hg commit' (or 'hg commit -A'). For these reasons, change the behavior of addremove so it does add forgotten files back. The problem is with scmutil._interestingfiles(), which reports the file as removed, so scmutil.addremove() does not add it. Fix by teaching _interestingfiles() to report forgotten files separately from removed files and make addremove() add forgotten files back. However, do not treat forgotten files as sources for rename detection. Note that since removed and forgotten files are treated the same before this change, forgotten files were considered sources for rename detection. Also update the other caller, marktouched(), in the same way as addremove().

add: add back forgotten files even when not matching exactly (BC) I accidentally did 'hg forget .' and tried to undo the operation with 'hg add .'. I expected the files to be reported as either modified or clean, but they were still reported as removed. It turns out that forgotten files are only added back if they are listed explicitly, as shown by the following two invocations. This makes it hard to recover from the mistake of forgetting a lot of files. $ hg forget README && hg add README && hg status -A README C README $ hg forget README && hg add . && hg status -A README R README The problem lies in cmdutil.add(). That method checks that the file isn't already tracked before adding it, but it does so by checking the dirstate, which does have an entry for forgotten files (state 'r'). We should instead be checking whether the file exists in the workingctx. The workingctx is also what we later call add() on, and that method takes care of transforming the add() into a normallookup() on the dirstate. Since we're changing repo.dirstate into wctx, let's also change repo.walk into wctx.walk for consistency (repo.walk calls wctx.walk, so we're simply inlining the call).

context.status: explain "caching reasons" more fully Where we "load earliest manifest first for caching reasons", elaborate on what "caching reasons" refers to. Text provided by Matt in http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/73235/focus=73578.

localrepo: rename revlog.maxchainlen to format.maxchainlen This is more consistent with other option names, as spotted by Pierre-Yves. Thanks!

revlog: add config variable for limiting delta-chain length The current heuristic for deciding between storing delta and full texts is based on ratio of (sizeofdeltas)/(sizeoffulltext). In some cases (for example a manifest for ahuge repo) this approach can result in extremely long delta chains (~30,000) which are very slow to read. (In the case of a manifest ~500ms are added to every hg command because of that). This commit introduces "revlog.maxchainlength" configuration variable that will limit delta chain length.

debugrevlog: fix computing chain length in debugrevlog -d The chain length was computed correctly only when generaldelta feature was enabled. Now it's fixed. When generaldelta is disabled the base revision in revlog index is not the revision we have delta against - it's always previous revision. Instead of incorrect chainbaseandlen in command.py we are now using two single-responsibility functions in revlog.py: - chainbase(rev) - chainlen(rev) Only chainlen(rev) was missing so it was written to mimic the way the chain of deltas is actually found during file reconstruction.

transaction: factorise append-only file registration The addition is done in two different places but differs slightly. We factorise this addition to ensure it is consistent in all places.

transaction: document `tr.add`

transaction: drop backupentries logic from startgroup and endgroup The `startgroup` and `endgroup` methods are used in a very specific context to wrap a very specific operation (revlog truncation). It does not make sense to perform any other operations during such a "group" (eg:file backup). There is currently no user of backupfile during a "group" so we drop the group-specific code and restrict authorized operations during "group".

transaction: document startgroup and endgroup These enigmatic methods are only used in repair. We document them to clarify there purpose and user.

transaction: mark backup-related attributes private As the transaction is gaining more functions and attributes, it is important to clarify what is part of the public API.

transaction: document the contents of `tr.backupentries` Now that all items are known we can document it.

transaction: drop the third item in `tr.backupentries` This third item is always None and never used.

rebase: fix rebase with no common ancestors (issue4446) The new rebase revset didn't check for the case when there are no common ancestors. Now it does. The new behavior should be the same as the pre-3.2 behavior. Added a test.

test-run-tests: accept more levels of precision and trailing ws (issue4440) simplejson produces slightly different output from the built-in json module, specifically: * It uses 0.000 instead of 0.0000 * It likes to put a trailing space after a comma This change works around both of those variations.

merge with stable

changegroup.cg2packer: lookup 'group' via inheritance chain This lets extensions insert themselves in the class hierarchy.

context.status: only filter suspect symlinks in the dirstate status We don't care about filtering out symlinks that have already been committed with full content, only those that have been accidentally resolved in the working directory.

context.status: inline _poststatus() By inlining _poststatus() into _buildstatus(), it becomes clearer that it is only called for the workingctx.

context.status: remove now-empty _prestatus()

context.status: call _dirstatestatus() from within _buildstatus() By making the call to _dirstatestatus() within _buildstatus(), it becomes clearer that it's called only for the workingctx.

context.status: move manifest caching trick to _buildstatus() In basectx._buildstatus(), we read the manifests for the two revisions being compared. For "caching reasons" unknown to me, it is better to read the earlier manifest first, which basectx._prestatus() takes care of. However, if the 'self' context is a committablectx and the 'other' context is the parent of the working directory (as in the very common case of plain "hg status"), there is no need to read any manifests at all -- all that's needed is the dirstate status. To avoid reading the manifests, _prestatus() is overridden in committablectx and avoids calling its super method, and _buildstatus() calls its super method only if the 'other' context is not the parent of the working directory. It seems easier to follow what's happening if we move the pre-fetching to _buildstatus() just before the place where the manifests are fetched. We just need to add an extra check that the revision is not None to handle the case that was previously handled by subclass overriding. That also makes it safe for committablectx._prestatus() to call its parent, although the latter now becomes empty, so we won't bother.

context.status: remove unused arguments from _matchstatus()

context.status: remove overriding in workingctx The workingctx method simply calls the super method. The only effect it has is that it uses a different default argument for the 'other' argument. The only in-tree caller is patch.diff, which always passes an argument to the method, so it should be safe to remove the overriding. Having the default argument depend on the type seems rather dangerous anyway.

synthrepo: when adding files, ensure new path is not a directory

synthrepo: synthesized dates must be positive, fit in 32-bit signed ints

discovery: test coverage for issue4438 / 86c35b7ae300 / 73cfaa348650 The randomness in the discovery protocol made this problem hard to reproduce. The test mocks random.sample to make sure we hit the problem every time. The set iteration order also made the output unstable ... but with the issue fixed, it is stable.

hgweb: fix a crash when using web.archivesubrepos A matcher is required when enabling the subrepo option on archival.archive(), because that calls match.narrowmatcher(), which accesses fields on the object. It's therefore probably a bad idea to default the matcher to None on archive(), but that's a fix for default.

tests: introduce a subrepository to test-archive.t This will be used in an upcoming patch to add coverage for web.archivesubrepos.

test-status-rev: add tests for plain dirstate and inter-revision status We have tests for the status across from '.^' to the working copy. It makes sense to have the similar tests for the inter-revision status between '.^' and '.' and for the dirstate status in the same place.

test-status-rev: remove unnecessary initial commit The initial commit was there when we had a group of tests that compared against an empty base, but since those tests no longer exist, we can drop the empty commit.

test-status-rev: use one glob for each expected status It's getting a little hard to read the ~30 calls to 'hg status' with one per file. Instead, let's use one glob for each expected status. For example, modified files can be listed with 'glob:content1_*_content[23]-tracked'. That also nicely becomes an explanation for why each status is expected.

test-status-rev: remove duplicate tests The second group of tests in test-status-rev compare to an empty revision. The first group of tests that compare to the first commit should be testing all the same states with the missing_* files, so drop the second group of tests.

changegroup: sparsely populate fnodes Previously, fnodes had a key and empty dict value for every element in changedfiles. This is somewhat wasteful. Empty dicts in CPython consume a lot more memory than you would expect - 280 bytes. On mozilla-central, which has ~190,000 files/fnodes keys, the previous loop populating fnodes allocated 91,924 KB of memory, most of that for the empty dicts. With this patch in place, our peak RSS during mozilla-central clone drops: before: 364,356 KB after: 326,008 KB delta: -38,348 KB When combined with the previous patch, total peak RSS decrease is now 190,116 KB.

changegroup: don't store unused value on fnodes (issue4443) The contents of fnodes are only accessed once per key. It is wasteful to cache the value since nobody will use it. Before this patch, the caching of unused data in fnodes was effectively causing a memory leak during the file streaming part of bundle creation. On mozilla-central (which has ~190,000 entries in fnodes), this patch has a significant impact on RSS at the end of generate(): before: 516,124 KB after: 364,356 KB delta: -151,768 KB The origin of this code can be traced back to 627cd7842e5d and has been with us since the 2.7 release.

changegroup: don't define lookupmf() until it is needed lookupmf() is currently defined earlier than when it is needed. Future patches further refactoring this code will be easier to read when lookupmf() is in its new home.

mail: actually use the verifycert config value The mail module only verifies the smtp ssl certificate if 'verifycert' is enabled (the default). The 'verifycert' can take three possible values: - 'strict' - 'loose' - any "False" value, eg: 'false' or '0' We tested the validity of the third value, but never converted it to actual falseness, making 'False' an equivalent for 'loose'. This changeset fixes it.

exchange: use the postclose API on transaction As with changegroup, we should wait for the transaction to be really closed before scheduling hook execution.

changegroup: use the 'postclose' API on transaction The post-transaction hooks run after the lock release (because hooks may want to touch the repository), but they must only run if the transaction is successfully closed. We use the new 'addpostclose' method on transaction to register a callback installing this post-lock-release call.

transaction: allow registering a post-close callback The addchangegroup code considers the transaction done after a 'tr.close()' call and schedules the hook's execution for after lock release. In the nested transaction case, the transaction is not yet committed and we must delay this scheduling. We add an 'addpostclose' method (like the 'addpending' and 'addfinalize' ones) that registers code to be run if the transaction is successfully committed.

exchange: swap "push" for "pull" in pulloperation docstring

exchange: prepare kwargs for bundle2 part generation exactly once

exchange: fix indentation in _pullchangeset

dagutil: fix id/ix typos in docstrings

patchbomb: extract 'getpatchmsgs' closure into its own function Keep marching toward the promised land of simplification!

patchbomb: extract 'makeintro' closure into its own function Keep marching toward the promised land of simplification!

patchbomb: extract 'getbundlemsgs' closure in its own function Keep marching toward the promised land of simplification!

patchbomb: extract 'getdescription' closure in its own function Keep marching toward the promised land of simplification!

patchbomb: extract 'getbundle' closure in its own function Keep marching toward the promised land of simplification!

patchbomb: extract 'getpatches' closure in its own function Keep marching toward the promised land of simplification!

patchbomb: extract 'getoutgoing' closure into its own function The patchbomb command is a gigantic 300 line function full of closures. As a first step to simplify it in smaller bits, I'm extracting the closures into full featured functions. The first victim is 'getoutgoing'. It gains a docstring in the process.

bundle2: handle empty 'b2x:changegroup' value in push and pull Changeset e4dc2b0be056 added advertising of supported changegroup version through the new 'b2x:changegroup' capability. However, this capability is not new and has been around since 3.1 with an empty value. This makes new clients unable to push to 3.2 servers through bundle2 as they cannot find a common changegroup version to use from and empty list. Treating empty 'b2x:changegroup' value as old client fixes it.

bundle2: drop duplicated definition of 'b2x:exchange' This bundle2 capability is going to be dynamically computed in 'getrepocaps'. We do not need to include it in the static value.

convert: use git diff-tree -Cn% instead of --find-copies=n% for older git The option --find-copies was added in a later git version than the one included in Debian squeeze-lts (1.7.2.5), probably around 1.7.4.

changelog: rely on transaction for finalization Instead of calling 'cl.finalize()' by hand (possibly at a bogus time) we register it in the transaction during 'delayupdate' and rely on 'tr.close()' to call it at the right time.

transaction: allow registering a finalization callback The new 'addfinalize' method allows people to register a callback to be triggered when the transaction is closed. This aims to get rid of explicit calls to 'changelog.finalize'. This also obsoletes the 'onclose' function but removing it is not in the scope of this series.

changelog: handle writepending in the transaction The 'delayupdate' method now takes a transaction object and registers its '_writepending' method for execution in 'transaction.writepending()'. The hook can then use 'transaction.writepending()' directly. At some point this will allow the addition of other file creation during writepending.

transaction: add 'writepending' logic The contents of the transaction must be flushed to disk before running a hook. But it must be flushed to a special file so that the normal reader does not use it. This logic is currently in the changelog only. We add some facility to register such operations in the transaction itself.

changelog: rework the delayupdate mechanism The current way we use the 'delayupdate' mechanism is wrong. We call 'delayupdate' right after the transaction retrieval, then we call 'finalize' right before calling 'tr.close()'. The 'finalize' call will -always- result in a flush to disk, making the data available to all readers. But the 'tr.close()' may be a no-op if the transaction is nested. This would result in data: 1) exposed to reader too early, 2) rolled back by other part of the transaction after such exposure So we need to end up in a situation where we call 'finalize' a single time when the transaction actually closes. For this purpose we need to be able to call 'delayupdate' and '_writepending' multiple times and 'finalize' once. This was not possible with the previous state of the code. This changeset refactors the code to makes this possible. We buffer data in memory as much as possible and fall-back to writing to a ".a" file after the first call to '_writepending'.

merge with stable

bookmarks: fix formatting of exchange message (issue4439) The message formatting was crashing when doing explicit pulling `hg pull -B X`. This changeset fix it and improved the test coverage.

test-status-rev: document one more broken test The status for missing_content2_content2-untracked doesn't get reported at all. Since the file does exist in the working copy, it should reported as unknown. Document that in the test.

test-status-rev: use common script for generating file history Start using the generate-working-copy-states.py script that's shared with test-revert.t, instead of creating the states manually in the test. This adds several states that are currently missing. We will start checking those states later.

test-status-rev: use same names as from generate-working-copy-states To prepare for using generate-working-copy-states.py for generating the files and their content, let's start by renaming the files according to the naming scheme used by that script.

test-revert: move embedded script to its own file Move the gen-revert-cases.py out of test-revert.t into its own file so we can reuse it from other tests (specifically test-status-rev.t).

test-revert: simplify generation of files With the recent change in naming of the generated files, it becomes much easier to generate the files by iterating over all the possible states than over the state transitions.

merge with stable

discovery: indices between sample and yesno must match (issue4438) 3ef893520a85 changed 'sample' from a list to a set. The iteration order is thus undefined and the yesno indices are not stable. To solve this, repeat the listification and comment from elsewhere in the code. Note: the randomness in the discovery protocol can make this problem hard to reproduce.

discovery: limit 'all local heads known remotely' to real 'all' (issue4438) 3ef893520a85 made it possible that the initial head check didn't include all heads. If that is the case, don't use the early exit just because this random sample happened to be 'all known'. Note: the randomness in the discovery protocol can make this problem hard to reproduce.

largefiles: avoid printing messages while rebasing by "_lfstatuswriters" Putting "lambda *msg, **opts: None" (= avoid printing messages always) into "_lfstatuswriters" while rebasing makes explicit passing "printmessage = False" for "updatelfiles()" useless. This patch also removes setting/unsetting "repo._isrebasing" in "overriderebase", because there is no code path referring it.

largefiles: get function to write status messages via "getstatuswriter()" This patch makes "updatelfiles()" get appropriate function to write largefiles specific status messages via "getstatuswriter()". This patch introduces None as "print messages if needed", because True (forcibly writing) and False (forcibly ignoring) are already used for "printmessage" of "updatelfiles". Subsequent patch will move "avoid printing messages only while automated committing" decision from caller of "updatelfiles()" into "getstatuswriter()".

largefiles: introduce "_lfstatuswriters" to customize status reporting "lfutil.getstatuswriter" is the utility to get appropriate function to write largefiles specific status out from "repo._lfstatuswriters". This patch uses "stack" with an element instead of flag like "_isXXXXing" or so, because: - the former works correctly even when customizations are nested, and - ensuring at least one element can ignore empty check

largefiles: update standins only at the 1st commit of "hg rebase --continue" Before this patch, "hg rebase --continue" may record incorrect standins, because largefiles extension always avoid updating standins while rebasing, even though largefiles in the working directory may be modified manually at the 1st commit of "hg rebase --continue". But, on the other hand, updating standins should be avoided at subsequent commits for efficiency reason. To update standins only at the 1st commit of "hg rebase --continue", this patch introduces state-full callable object "automatedcommithook", which updates standins by "lfutil.updatestandinsbymatch()" only at the 1st commit of resuming. Even after this patch, "repo._isrebasing = True" is still needed to avoid some status report while updating largefiles in "lfcommands.updatelfiles()". This is reason why this patch omits not "repo._isrebasing = True" in "overriderebase" but examination of "getattr(repo, "_isrebasing", False)" in "updatestandinsbymatch".

largefiles: introduce "_lfcommithooks" to abstract pre-committing procedures This changes allows to customize pre-committing procedures according to conditions. This patch uses "stack" with an element instead of flag like "_isXXXXing" or so, because: - the former works correctly even when customizations are nested, and - ensuring at least one element can ignore empty check

largefiles: factor out procedures to update standins for pre-committing This patch factors out procedures to update standins for pre-committing. This is one of preparations to avoid execution of such procedures according to invocation context. For example, resuming automated committing (e.g. "hg rebase --continue") should update standins at the 1st commit, because largefiles in the working directory may be modified manually. But on the other hand, it should avoid updating standins at subsequent committings for efficiency reason. For simplicity, this patch just moves procedures mechanically only with replacing below. - "self" => "repo" - "lfutil." => (none) - "orig" invocation => returning "match" Using "fstandin" instead "standin" as the name of local variable for the loop below is the only special care, because the latter shadows the same name function in "lfutil.py". [before] for standin in standins: lfile = lfutil.splitstandin(standin) if lfdirstate[lfile] != 'r': lfutil.updatestandin(self, standin) [after] for fstandin in standins: lfile = splitstandin(fstandin) if lfdirstate[lfile] != 'r': updatestandin(repo, fstandin)

largefiles: factor out procedures to update lfdirstate for post-committing Before this patch, procedures to update lfdirstate for post-committing are scattered in "lfilesrepo.commit". In the case of "hg commit" with patterns for target files ("Case 2"), lfdirstate is updated BEFORE real committing. This patch factors out procedures to update lfdirstate for post-committing into "lfutil.markcommitted", and makes it callable via "markcommitted" of the context passed to "lfilesrepo.commitctx". "markcommitted" of the context is called, only when it is committed successfully. Passing original "markcommitted" of the context is meaningless in this patch, but required in subsequent one to prepare something before invocation of it.

largefiles: remove meaningless code path for "hg pull --rebase" This patch removes "--rebase" specific code path for "hg pull" in "overridepull", because previous patch makes it meaningless: now, "rebase.rebase" ("orig" invocation in this patch) can update/commit largefiles safely without "repo._isrebasing = True". As a side effect of removing "rebase.rebase" invocation in "overridepull", this patch removes "nothing to rebase ..." message in "test-largefiles.t", which is shown only when rebase extension is enabled AFTER largefiles: before this patch: 1. "dispatch" invokes "pullrebase" of rebase as "hg pull" at first, because rebase wraps "hg pull" later 2. "pullrebase" invokes "overridepull" of largefiles as "orig", even though rebase assumes that "orig" is "pull" of commands 3. "overridepull" executes "pull" and "rebase" directly 3.1 "pull" pulls changesets and creates new head "X" 3.2 "rebase" rebases current working parent "Y" on "X" 4. "overridepull" returns to "pullrebase" 5. "pullrebase" tries to rebase, but there is nothing to be done, because "Y" is already rebased on "X". then, it shows "nothing to rebase ..." after this patch: 1. "dispatch" invokes "pullrebase" of rebase as "hg pull" 2. "pullrebase" invokes "overridepull" of largefiles as "orig" 3. "overridepull" executes "pull" as "orig" 4. "overridepull" returns to "pullrebase" 5. revision "Y" is not yet rebased, so "pullrebase" doesn't shows "nothing to rebase ..." As another side effect of removing "rebase.rebase" invocation, this patch fixes issue3861, which occurs only when rebase extension is enabled BEFORE largefiles: before this patch: 1. "dispatch" invokes "overridepull" of largefiles at first, because largefiles wrap "hg pull" later 2. "overridepull" executes "pull" and "rebase" explicitly 2.1 "pull" pulls changesets and creates new head "X" 2.2 "rebase" rebases current working parent, but fails because no revision is checked out in issue3861 case 3. "overridepull" returns to "dispatch" with exit code 1 returned from "rebase" at (2.2) 4. "hg pull" terminates with exit code 1 unexpectedly after this patch: 1. "dispatch" invokes "overridepull" of largefiles at first 2. "overridepull" invokes "pullrebase" of rebase as "orig" 3. "pullrebase" invokes "pull" as "orig" 4. "pullrebase" invokes "rebase", and it fails 5. "pullrebase" returns to "overridepull" with exit code 0 (because "pullrebase" ignores result of "pull" and "rebase") 6. "overridepull" returns to "dispatch" with exit code 0 returned from "rebase" at (5) 7. "hg pull" terminates with exit code 0

largefiles: wrap "rebase.rebase" for functions using it directly Before this patch, largefiles extension wraps only "rebase" in the command table by "extensions.wrapcommand". But there are some functions using "rebase.rebase" directly. Without special care for them, largefiles extension can't work correctly with such functions. In addition to it, "special care" often becomes complicated and awkward. For example: - "unshelve" can't get correct result of "rebase.rebase", because of lack of special care - special care for "hg pull --rebase" causes issue3861 This patch wraps "rebase.rebase" for functions using it directly. For simplicity, this patch keeps 'special care for "hg pull --rebase"'. It is removed in the subsequent patch.

changegroup: introduce cg2packer/unpacker cg2 supports generaldelta in changegroups, to be used in bundle2. Since generaldelta is handled directly in cg2, reordering is switched off by default.

push: send highest changegroup format supported by both side When using bundle2, we find the common subset of supported changegroup-packers and we pick the max of them. This allow to use generaldelta aware changegroups through bundle2.

getbundle: send highest changegroup format supported by both side When using bundle2, we find the common subset of supported changegroup-packers and we pick the max of them. This allow to use generaldelta aware changegroup through bundle2.

changegroup: allow use of different cg#packer in getchangegroupraw This will allow the use of general delta aware changegroup formats.

changegroup: introduce "raw" versions of some commands The commands getchangegroup, getlocalchangegroup and getsubset now each have a version ending in -raw. The raw versions return the chunk generator from the changegroup packer directly, without wrapping it in a chunkbuffer and unpacker. This avoids extra chunkbuffers in the bundle2 code path. Also, the raw versions can be extended to support alternative packers in the future, to be used from bundle2.

merge with stable

win32: remove Mercurial.ini file from Inno Setup installer (issue4435)

win32: fix win32 installers generation cd0c51c07e5f introduced a typo preventing a proper generation of the installers. Also remove ConcatenateFiles() function as it is no more required.

patchbomb: add label and color to the confirm output The current output is mostly a wall of text. This makes it hard to actually check something for people with lazy eyes. We use labels and colors to make it more joyful (and get the patch summaries to stand out). The colors have been arbitrarily choosen. They can be changed later if someone has a more scientific choice.

tests: write hgrc of more than two lines by using shell heredoc Here document should be readable than repeating echo commands.

perf: use a formatter for output We use a `formatter` object in the perf extensions. This allow the use of formatted output like json. To avoid adding logic to create a formatter and pass it around to the timer function in every command, we add a `gettimer` function in charge of returning a `timer` function as simple as before but embedding an appropriate formatter. This new `gettimer` function also return the formatter as it needs to be explicitly closed at the end of the command. example output: $ hg --config ui.formatjson=True perfvolatilesets visible obsolete [ { "comb": 0.02, "count": 126, "sys": 0.0, "title": "obsolete", "user": 0.02, "wall": 0.0199398994446 }, { "comb": 0.02, "count": 117, "sys": 0.0, "title": "visible", "user": 0.02, "wall": 0.0250301361084 } ]

bundle2: support a "version" argument in `changegroup` part When included, this mandatory parameter (mandatory == cannot be ignored) lets the part handler select the right cgunpacker class.

bundle2caps: advertise the available versions for changegroup packer This will let the bundle2 client and server detect what packer they should be using. This detection part is not done. I expect it to be done with the addition of the second packer (with generaldelta support).

changegroup: add a "packermap" dictionary to track different packer versions We only have "01" right now, but we should get general delta in soon. Bundle2 is expected to make use of this to advertise and select the right packer to use on both sides.

templater: don't overwrite the keyword mapping in runsymbol() (issue4362) This keyword remapping was introduced in e06e9fd2d99f as part of converting generator based iterators into list based iterators, mentioning "undesired behavior in template" when a generator is exhausted, but doesn't say what and introduces no tests. The problem with the remapping was that it corrupted the output for keywords like 'extras', 'file_copies' and 'file_copies_switch' in templates such as: $ hg log -r 142b5d5ec9cc --template "{file_copies % ' File: {file_copy}\n'}" File: mercurial/changelog.py (mercurial/hg.py) File: mercurial/changelog.py (mercurial/hg.py) File: mercurial/changelog.py (mercurial/hg.py) File: mercurial/changelog.py (mercurial/hg.py) File: mercurial/changelog.py (mercurial/hg.py) File: mercurial/changelog.py (mercurial/hg.py) File: mercurial/changelog.py (mercurial/hg.py) File: mercurial/changelog.py (mercurial/hg.py) What was happening was that in the first call to runtemplate() inside runmap(), 'lm' mapped the keyword (e.g. file_copies) to the appropriate showxxx() method. On each subsequent call to runtemplate() in that loop however, the keyword was mapped to a list of the first item's pieces, e.g.: 'file_copy': ['mercurial/changelog.py', ' (', 'mercurial/hg.py', ')'] Therefore, the dict for the second and any subsequent items were not processed through the corresponding showxxx() method, and the first item's data was reused. The 'extras' keyword regressed in de7e6c489412, and 'file_copies' regressed in 0b241d7a8c62 for other reasons. The common thread of things fixed by this seems to be when a list of dicts are passed to the templatekw._hybrid class.

revset-matching: call 'getset' on a 'fullreposet' Calling 'baseset(repo.changelog)' builds a list for all revisions in the repo. And we already have the lazy and efficient 'fullreposet' class for this purpose. This gives us the usual benefits of the fullreposet but it is less visible because the matching process itself is very expensive: revset) matching(100) before) wall 6.413281 comb 6.420000 user 5.910000 sys 0.510000 (best of 3) after) wall 6.173608 comb 6.170000 user 5.750000 sys 0.420000 (best of 3) However for some complex list, this provide a massive speedup revset) matching(parents(100)) before) wall 23.890740 comb 23.890000 user 23.450000 sys 0.440000 (best of 3) after) wall 6.382280 comb 6.390000 user 5.930000 sys 0.460000 (best of 3)

revset-parentspec: call 'getset' on a 'fullreposet' Calling 'baseset(repo.changelog)' builds a list for all revisions in the repo. And we already have the lazy and efficient 'fullreposet' class for this purpose. This gives us the usual benefits of the fullreposet: revset) 100^1 before) wall 0.002694 comb 0.000000 user 0.000000 sys 0.000000 (best of 897) after) wall 0.000997 comb 0.000000 user 0.000000 sys 0.000000 (best of 2324) revset) parents(100)^1 before) wall 0.003832 comb 0.000000 user 0.000000 sys 0.000000 (best of 587) after) wall 0.001034 comb 0.000000 user 0.000000 sys 0.000000 (best of 2309) revset) (100^1)^1 before) wall 0.005616 comb 0.000000 user 0.000000 sys 0.000000 (best of 405) after) wall 0.001030 comb 0.000000 user 0.000000 sys 0.000000 (best of 2258)

revset-children: call 'getset' on a 'fullreposet' Calling 'baseset(repo.changelog)' builds a list for all revisions in the repo. And we already have the lazy and efficient 'fullreposet' class for this purpose. This gives us the usual benefits of the fullreposet: revset) children(tip~100) before) wall 0.007469 comb 0.010000 user 0.010000 sys 0.000000 (best of 338) after) wall 0.003356 comb 0.000000 user 0.000000 sys 0.000000 (best of 755)

revset-ancestorspec: call 'getset' on a 'fullreposet' Calling 'baseset(repo.changelog)' builds a list for all revisions in the repo. And we already have the lazy and efficient 'fullreposet' class for this purpose. This gives us the usual benefits of the fullreposet: revset) 100~5 before) wall 0.002712 comb 0.000000 user 0.000000 sys 0.000000 (best of 918) after) wall 0.000996 comb 0.000000 user 0.000000 sys 0.000000 (best of 2493) revset) parents(100)~5 before) wall 0.003812 comb 0.010000 user 0.010000 sys 0.000000 (best of 667) after) wall 0.001038 comb 0.000000 user 0.000000 sys 0.000000 (best of 2361) revset) (100~5)~5 before) wall 0.005614 comb 0.000000 user 0.000000 sys 0.000000 (best of 446) after) wall 0.001035 comb 0.000000 user 0.000000 sys 0.000000 (best of 2424)

revset-rangeset: call 'getset' on a 'fullreposet' Calling 'baseset(repo.changelog)' builds a list for all revisions in the repo. And we already have the lazy and efficient 'fullreposet' class for this purpose. This gives us the usual benefit ofs the fullreposet: revset) 10:100 before) wall 0.002774 comb 0.000000 user 0.000000 sys 0.000000 (best of 797) after) wall 0.001977 comb 0.000000 user 0.000000 sys 0.000000 (best of 1244) revset) parents(10):parents(100) before) wall 0.005054 comb 0.000000 user 0.000000 sys 0.000000 (best of 481) after) wall 0.002060 comb 0.000000 user 0.000000 sys 0.000000 (best of 1056)

test-revert: make sure all 'tracked' files are really tracked When a file is missing in the 'parent' version and is tracked but missing in the working directory, which happens by the 'missing' or 'removed' types, and the 'clean' type in the working directory, the file does not exist in the working directory (unlike it would had the 'deleted' type been used). Thus, the *_missing_missing_tracked are not actually tracked and they end up testing the same state as *_missing_missing_untracked. To make them tracked, add a temporary file, just like we do for the delete case. For simplicity's sake, let's make sure the gen-revert-cases.py script always puts a file in the working directory, whether or not it's going to be deleted.

test-revert: sort by output filename again Future patches will change how the output of 'gen-revert-cases.py filelist' is generated, so now we want the order to depend on just the filename again.

test-revert: name files by state, not by state transition This is the main patch in a series. See motivation in earlier patch. In this patch, we actually change the names of the generated files. For example, the file that is currently called missing_clean becomes missing_missing_missing-tracked and it's clearer that it should be tracked. It turns out that since the state was not previously clear, it ended up testing an untracked state, which was the same as for missing_clean. We'll fix this in a later patch. Let's also change the content from (base,parent,wc) to (content1,content2,content3) to make them all the same length so they line up when displayed.

test-revert: temporarily sort by input states instead of output filename The next patch will change the names of the files produced by the script in test-revert. In order to reduce the size and increase the clarity of the next patch, make the order produced by the internal 'gen-revert-cases.py filelist' command independent of the filenames.

test-revert: put content, not keys, into 'combination' By putting the file content rather than keys in the 'combination' list, we restrict the knowledge of 'ctxcontent' and 'wccontent' to the loop generating the combinations. That will make it easier to replace the generation code.

test-revert: replace 'removed' in working copy with 'untracked-deleted' The 'wccontent' variable has eight different states, four of them tracked, and the other four untracked (at least when the file existed in the parent revision). Among these eight states, 'removed' sticks out by lacking the 'untracked-' prefix despite resulting in an untracked state. To make the symmetry clearer, and to prepare for future patches, rename 'removed' to 'untracked-deleted', which is exactly what it is. Note that, unlike 'remove', 'deleted' is configured in gen-revert-cases.py to have content in the working directory and that that content is instead expected to be removed in the test script. However, no changes are needed to the test script, since it already contains 'hg forget *untracked*' and 'rm *deleted*', which together have the same effect as 'hg remove'. See additional motivation in earlier patch.