subrepo: add 'cat' support for git subrepos V2: use 'self._ctx.node()' instead of 'rev' in makefileobj. As Matt Harbison mentioned, using 'rev' does not make sense, since we'd be passing a git revision to the top-level Mercurial repository.

merge with stable

Added signature for changeset fbdd5195528f

Added tag 3.3 for changeset fbdd5195528f

merge with i18n

i18n-ja: synchronized with 9a391d720cf9

i18n-pt_BR: synchronized with 448bb32b8ee6

filectx: use _descendantrev in parents() This lets us be lazy about linkrev adjustments when tracing history.

filectx: if we have a _descendantrev, use it to adjust linkrev This lets us use _adjustlinkrev lazily.

copies: use linkrev for file tracing limit This lets us lazily evaluate _adjustlinkrev.

filectx: use linkrev to sort ancestors We're going to make rev() lazily do _adjustlinkrevs, and we don't want that to happen when we're quickly tracing through file ancestry without caring about revs (as we do when finding copies). This takes us back to pre-linkrev-correction behavior, but shouldn't regress us relative to the last stable release.

_adjustlinkrev: reuse ancestors set during rename detection (issue4514) The new linkrev adjustement mechanism makes rename detection very slow, because each file rewalks the ancestor dag. To mitigate the issue in Mercurial 3.3, we introduce a simplistic way to share the ancestors computation for the linkrev validation phase. We can reuse the ancestors in that case because we do not care about sub-branching in the ancestors graph. The cached set will be use to check if the linkrev is valid in the search context. This is the vast majority of the ancestors usage during copies search since the uncached one will only be used when linkrev is invalid, which is hopefully rare.

filectx: move _adjustlinkrev to a method We are going to introduce some wider caching mechanisms during linkrev adjustment. As there is no specific reason to not be a method and some reasons to be a method, let's make it a method.

revset: raise RepoLookupError to make present() predicate continue the query Before this patch, "bookmark()", "named()" and "tag()" predicates raise "Abort", when the specified pattern doesn't match against existing ones. This prevents "present()" predicate from continuing the query, because it only catches "RepoLookupError". This patch raises "RepoLookupError" instead of "Abort", to make "present()" predicate continue the query, even if "bookmark()", "named()" or "tag()" in the sub-query of it are aborted. This patch doesn't contain raising "RepoLookupError" for "re:" pattern in "tag()", because "tag()" treats it differently from others. Actions of each predicates at failure of pattern matching can be summarized as below: predicate "literal:" "re:" ---------- ----------- ------------ bookmark abort abort named abort abort tag abort continue (*1) branch abort continue (*2) ---------- ----------- ------------ "tag()" may have to abort in the (*1) case for similarity, but this change may break backward compatibility of existing revset queries. It seems to have to be changed on "default" branch (with "BC" ?). On the other hand, (*2) seems to be reasonable, even though it breaks similarity, because "branch()" in this case doesn't check exact existence of branches, but does pick up revisions of which branch matches against the pattern. This patch also adds tests for "branch()" to clarify behavior around "present()" of similar predicates, even though this patch doesn't change "branch()".

templatekw: re-add showtags() to list tags keyword up in online help Changeset d69a7fc68ad5 removed "showtags()" definition for "tags" template keyword from "templatekw.py", because "namespaces" puts a helper function for it into template keyword map automatically. This works correctly from the point of view of templating functionality. But on the other hand, it removed "tags" template keyword from "hg help templates" unexpectedly, because online help text is built before "namespaces" puts a helper function for "tags" into template keyword map. This patch is a kind of backing d69a7fc68ad5 out, but this implements "showtags()" with newly introduced "shownames()" instead of originally used "showlist()".

largefiles: don't interfere with logging normal files The previous code was adding standin files to the matcher's file list when neither the standin file nor the original existed in the context. Somehow, this was confusing the logging code into behaving differently from when the extension wasn't loaded. It seems that this was an attempt to support naming a directory that only contains largefiles, as a test fails if the else clause is dropped entirely. Therefore, only append the "standin" if it is a directory. This was found by running the test suite with --config extensions.largefiles=. The first added test used to log an additional cset that wasn't logged normally. The only relation it had to file 'a' is that 'a' was the source of a move, but it isn't clear why having '.hglf/a' in the list causes this change: @@ -47,6 +47,11 @@ Make sure largefiles doesn't interfere with logging a regular file $ hg log a --config extensions.largefiles= + changeset: 3:2ca5ba701980 + user: test + date: Thu Jan 01 00:00:04 1970 +0000 + summary: d + changeset: 0:9161b9aeaf16 user: test date: Thu Jan 01 00:00:01 1970 +0000 The second added test used to complain about a file not being in the parent revision: @@ -1638,10 +1643,8 @@ Ensure that largefiles doesn't intefere with following a normal file $ hg --config extensions.largefiles= log -f d -T '{desc}' -G - @ c - | - o a - + abort: cannot follow file not in parent revision: ".hglf/d" + [255] $ hg log -f d/a -T '{desc}' -G @ c | Note that there is still something fishy with the largefiles code, because when using a glob pattern like this: $ hg log 'glob:sub/*' the pattern list would contain '.hglf/glob:sub/*'. None of the tests show this (this test lives in test-largefiles.t at 1349), it was just something that I noticed when the code was loaded up with print statements.

discovery: properly exclude locally known but filtered heads The conditional was a bit too narrow and produced buggy result when a node was present in both common and heads (because it pleased the discovery) and it was locally known but filtered. This resulted in buggy getbundle request and server side crash.

test: make test-extdiff resilient to /usr/bin/echo My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.

obsstore: make the invalid markers check wrap-able Some evolve user ignored the invalid markers for about two years and still have some of them in some repository. This lead to plain abort whenever mercurial try to open such repo. We need reinstall some way to clean this up in the evolve extension. For this purpose, we need the checker code wrap-able independently. This is scheduled for stable as this issue is blocking some evolve user.

convert: replace revision references in messages if they are >= short hashes Convert will try to find references to revisions in commit messages and replace them with references to the converted revision. It will take any string that looks like a hash (and thus also decimal numbers) and look it up in the source repo. If it finds anything, it will use that in the commit message instead. It would do that for all hex digit sequences of 6 to 40 characters. That was usually no problem for small repos where it was unlikely that there would be a matching 6 'digit' hash prefix. It was also no problem on repos with less than 100000 changesets where numbers with 6 or more digits not would match any revision number. With more than 100000 revisions random numbers in commit messages would be replaced with a "random" hash. For example, 'handle 100000 requests' would be changed to to 'handle 9117c6 requests'. Convert could thus not really be used on real repositories with more than 100000 changesets. The default hash length shown by Mercurial is 12 'digits'. It is unexpected and unwanted that convert by default tries to replace revision references that use less than that amount of 'digits'. To fix this, don't match strings that are less than the default hash size of 12 characters.

merge: mark .hgsubstate as possibly dirty before submerge for consistency Before this patch, failure of updating subrepos may cause inconsistent ".hgsubstate". For example: 1. dirstate entry for ".hgsubstate" of the parent repo is filled with valid size/date (via "hg state" or so) 2. "hg update" is invoked at the parent repo 3. ".hgsubstate" of the parent repo is updated on the filesystem as a part of "g"(et) action in "merge.applyupdates" 4. it is assumed that size/date of ".hgsubstate" on the filesystem aren't changed from ones at (1) this is not so difficult condition, because just changing hash ids (every ids are same in length) in ".hgsubstate" doesn't change the file size of it 5. "subrepo.submerge()" is invoked to update subrepos 6. failure of updating in one of subrepos raises exception (e.g. "untracked file differs") 7. "hg update" is aborted without updating dirstate of the parent repo dirstate entry for ".hgsubstate" still holds size/date at (1) Then, ".hgsubstate" of the parent repo is treated as "CLEAN" unexpectedly, because updating ".hgsubstate" at (3) doesn't change size/date of it on the filesystem: see assumption at (4). This inconsistent ".hgsubstate" status causes unexpected behavior, for example: - "hg revert" forgets to revert ".hgsubstate" - "hg update" misunderstands that (not yet updated) subrepos diverge (then, it shows the prompt to confirm user's decision) To avoid inconsistent ".hgsubstate" status above, this patch marks ".hgsubstate" as possibly dirty before "submerge" invocation. "normallookup"-ed (= dirty) dirstate should be written out, even if processing is aborted by failure. This patch marks ".hgsubstate" as possibly dirty before "submerge", also when it is removed or merged while merging, for safety. This should prevent Mercurial from misunderstanding inconsistent ".hgsubstate" as clean. To satisfy conditions at (1) and (4) above, this patch uses "hg status --config debug.dirstate.delaywrite=2" (to fill valid size/date into dirstate) and "touch" (to fix date of the file).

rebase: ensure rebase revision remains visible (issue4504) Before this changeset rebase was getting very confused if any revision in the rebase set became hidden. This was fairly easy to achieve if a rebased revision was made visible by the working copy location. The rebase process would update somewhere else and the revision would become hidden. To work around this issue, we ensure rebased revisions remain visible for the whole process. This is a simple change suitable for stable. More subtle usage of unfiltered repository in rebase may solve this issue more cleanly.

extdiff: reintroduce backward compatibility with manual quoting of parameters 72a89cf86fcd broke things ... and the following cleanups didn't fix all issues. It didn't work with the diffargs shipped in mergetools.rc with explicit quoting. Parameters would end up with being quoted twice - especially if they really needed quoting. To work around that, look for explicit quotes around the variables that will be substituted with proper quoting. Also accept an additional prefix so we can handle both --foo='$parent' and '--foo=$parent' It will however still fail if the user intentionally place the variable inside a quoted string, as in 'parent $parent is on the left' There is currently no good way to handle that, short of knowing exactly which quoting mechanism will be used.

mergetools: drop incorrect quoting of diffargs variables 72a89cf86fcd introduced automatic quoting of diffargs in a not entirely backwards compatible way. That rendered some of the configuration in mergetools.rc invalid. It would fail when running extdiff on a single file with a name that needed quoting. Before: $ hg config merge-tools.meld.diffargs -a --label='$plabel1' $parent --label='$clabel' $child $ hg --config extdiff.meld= -v --debug meld running "/usr/bin/meld -a --label=''sp ace@0'' '.../Z.b7a65a1d2f84/sp ace' --label=''sp ace'' '.../sp ace'" in ... meld: error: too many arguments (wanted 0-3, got 4) After: $ hg config merge-tools.meld.diffargs -a --label=$plabel1 $parent --label=$clabel $child $ hg --config extdiff.meld= -v --debug meld running "/usr/bin/meld -a --label='sp ace@0' '.../Z.b7a65a1d2f84/sp ace' --label='sp ace' '.../sp ace'" in ... (success)

namespace: introduce logfmt to show l10n-ed messages for hg log correctly Before this patch, "_()" is used incorrectly for "tag:" and "bookmark:" fields. "changeset_printer()" looks up keys composed at runtime, and it prevents "xgettext" command from getting strings to be translated from source files. Then, *.po files merged with updated "hg.pot" lose msgids for "tag:" and "bookmark:". This patch introduces "logfmt" information into "namespace" to show l10n-ed messages "hg log" (or "changeset_printer()") correctly. For similarity to other namespaces, this patch specifies "logfmt" for "branches" namespace, even though it isn't needed (branch information is handled in "changeset_printer()" specially). To find related code paths out easily, this patch adds "i18n: column positioning ..." comment to the line composing "logfmt" by default, even though this line itself doesn't contain any strings to be translated.

osutil: fix memory leak of PyBytes of path in statfiles Spotted with cpychecker.

revert: move prefetch to after the actions logic The prefetch logic came before the actual population of the actions collection, so it was always being passed an empty action list. This fixes it by moving it to after that logic. The only consumer of this function at the moment is remotefilelog, and I verified it works with this change.

diffhelpers: fix botched return statement from c8e7fa41bfc5 Spotted by Sean Farley using clang.

subrepo: don't abort in add when non-hg subrepos are present (issue4513) This change should have been part of 9994f45ba714.

osutil: fix leak of stat in makestat when Py_BuildValue fails Spotted with cpychecker.

osutil.c: clean up space before a tab

dirs: fix leak of iterator in dirs_fromiter Spotted with cpychecker.

diffhelpers: verify hline was created before using it Found with cpychecker.

largefiles: revert to lfilesrepo.status() being an unfiltered method This effectively reverts 67d63ec85eb7, which caused some normal file copies to not be displayed as copies. Other normal file copies could be displayed- the exact reason isn't clear. This also adds two tests that were failing prior to this backout, so that this can be sorted out next cycle. The difference between copy cases that worked and those that didn't seemed to be in copies.pathcopies(). When largefiles isn't enabled for the changed test, or lfstatus is not set in the commands.status() override, 'y.ancestor(x) == x'. That wasn't true otherwise, which fell through to the _chain() method. In this case, the copy is removed in the criss cross loop. 'y.ancestor(x)' returns a context.changectx type, while 'x' is a lfilesctx type in the failing case. I tried adding the ancestor method to the lfilesctx class to change the type of the ancestor context, however the context when printed as a string then gains a '+'. This points to it being a context.committablectx, which clearly isn't correct for an ancestor. Possibly the problem is the lfilesctx needs to subclass context.committablectx in some cases, but context.changectx in others, within the same invocation? I'm not sure how to pull that off, and backing out this change is safer during the freeze. As to the status changing when a path is specified, I haven't looked into it yet.

test-tools: portability tweak

revset: fix ancestors(null) to include null revision (issue4512) Since 13c0327eeb6f, null parent is explicitly excluded. So, there is no reason to have nullrev in the initial seen set.

log: use rev() to build revset of --follow option from numeric revision startrev can be -1.

revset: allow rev(-1) to indicate null revision (BC) This can simplify the conversion from numeric revision to string. Without it, we have to handle -1 specially because repo['-1'] != repo[-1]. The -1 revision is not officially documented, but this change makes sense assuming that "rev(%d)" exists for scripting or third-party tools.

extensions: don't quit loading extensions in the middle if traceback is on This was introduced way back in 2006 (rev 1f6d520557ec) as sys.exit(0) if loading an extension failed when --traceback was on, then at some point morphed into a 'return 1' in a function that otherwise returns nothing. At this point, if ui.traceback is enabled and if loading an extension fails for whatever reason, including one as innocent as it not being present, we leave any extensions loaded so far in a bogus half-initialized state. That doesn't really make any sense.

test-hgweb: fix shutdown race Logfiles weren't necessarily being flushed before being read.

tests: invoke hg command indirectly from shell script to run on Windows Before this patch, test-tag.t can't run successfully on Windows, because: - quoted hg command ('"hg"') prevents "hg.bat" from working correctly (only at testing with pure Python build) "%~f0" and "%~dp0hg" in "hg.bat" cause unexpected result in this case. BTW, quoted "\path\to\hg" works correctly. - "`pwd`" in the command line is expanded unexpectedly not "C:\path\to\TESTTMP" but "C;C:\path\to\TESTTMP"

log: evaluate filesets on working copy, not its parent When running "hg log 'set:added()'", we create two matchers: one used for producing the revset and one used for finding files to match. In 1fd352aa08fc (graphlog: evaluate FILE/-I/-X filesets on the working dir, 2012-02-26), we started passing a revision argument along from what's currently in cmdutil._makelogrevset() to revset._matchfiles(). When the revision was an empty string, it referred to the working copy. This was subtly done with "repo[rev or None]". Then, in f2aeff8a87b6 (revset: avoid recalculating filesets, 2014-10-22), that conversion from empty string to None was lost. Note that repo[''] is equivalent to repo['.'], not repo[None]. The consequence of this, to the user, is that when running "hg log 'set:added()'", the file matcher matches files added in the working copy, while the revset matcher matches revisions that touch files added in the parent of the working copy. As a result, only revisions that touch any files added in the parent of the working copy will be considered, but they will only be included if they also touch files added in the working copy. Fix the bug by converting '' to None again, but make it a little more explicit this time (plus, we now have tests for it).

fileset: add tests of generated working copy states

parsers: avoid leaking several PyObjects in index_stats Found with cpychecker.

parsers: don't leak a reference to raise_revlog_error on success Found with cpychecker.

parsers: don't leak a tuple in pack_dirstate Spotted with cpychecker.

parsers.c: fix a memory leak in index_commonancestorsheads Spotted with cpychecker.

parsers: avoid leaking obj in index_ancestors PySequence_GetItem returns a new reference. Found with cpychecker.

parsers: don't leak references to sys et al in check_python_version Found with cpychecker.

parsers: fix leak of err when asciilower hits a unicode decode error This is one of many errors detected in parsers.c by cpychecker[1]. I haven't gone through all of them yet. 1: https://gcc-python-plugin.readthedocs.org/en/latest/index.html

largefiles: use 'default' path for pulling largefiles, not 'default-push' The put parameter has been unused since day 0.

osx: patch .pax.gz files in pkg bundles so they extract as root (issue4081) The packages has to be installed by root but they would be installed insecurely, owned by the uid of the unprivileged user that made the package. The local user with that uid could thus write to /usr/local/bin/hg . bdist_mpkg calls out to pax to create the package, but pax do apparently not have the power to control what it is writing. Instead, patch the pax files and set their uid fields to 0 before they are wrapped in a dmg.

repair._bundle: fix traceback for bad config value On IRC, rom1dep reported a traceback[1] from setting experimental.strip-bundle2-version to True. This diff catches unexpected values and falls back to the non-experimental bundle1 implementation after issuing a warning. [1] http://gist.tamytro.org/_admin/gists/qXcdQLwtApgy6e3NwWgl

subrepo: correctly add newline for git subrepo diffs Previously, git subrepo diffs did not have a newline at the end. This caused multiple subrepo diffs to be joined on the same line. Additionally, the command prompt after the diff still contained a part of the diff.

tests: discard useless "(glob)" in "reverting subrepo" lines

check-code.py: avoid warning against "reverting subrepo ..." lines Before this patch, "reverting subrepo subrepo/path" lines in *.t test files require "(glob)", because such lines are recognized as "reverting path/to/managed/file" by "check-code.py". On the other hand, "(glob)" for such "reverting ..." line is recognized as useless by "runt-tests.py", because subrepo paths shown in such lines are always normalized by "util.pconvert". And this causes "no result code from test" warning. As a preparation for discarding "(glob)" from such lines in subsequent patch, this patch avoids warning against them, by adding negative lookahead assertion "(?!subrepo )" to the regexp.

run-tests.py: inherit --pure option from outer run-tests.py execution Before this patch, "test-run-tests.t" doesn't test "run-tests.py" with "--pure", even if outer "run-tests.py" is executed with it. This patch uses not "HG_RUN_TESTS_PURE" but "HGTEST_RUN_TESTS_PURE", because "HG_" prefixed environments are forcibly dropped in "_getenv()". This is also useful to run "run-tests.py" successfully by "run-tests.py --pure" on Windows without any compilation tools (like VisualStudio).

hg.bat: return exit code explicitly for indirect invocation When "hg.bat" is invoked via interactive shell "cmd.exe" on Windows, it can store own exit code into ERRORLEVEL correctly, regardless of explicit "exit" statement in it: "cmd.exe" seems to hold ERRORLEVEL updated by the last command in the batch file (= "python hg", in "hg.bat" case). On the other hand, "hg.bat" is invoked indirectly via "subprocess.Popen" (e.g. shell alias, hooks, hgclient and so on), the parent process always receives exit code 0 from spawned "hg.bat": batch files on Windows seem not to be really spawned like as shell scripts on UNIX, but to be executed in the "cmd.exe" process. This patch returns exit code explicitly for indirect invocation. "/b" should be specified for "exit" to prevent "cmd.exe" from being terminated when "hg.bat" is invoked interactively from it.

run-tests.py: execute hghave with same env vars as ones for actual tests Before this patch, "run-tests.py" executes "hghave" process without any modifications for environment variables, even though actual tests are executed with LC_ALL, LANG and LANGUAGE explicitly assigned "C". When "run-tests.py" is executed: - with non-"C" locale environment variables on any platforms, or - without any explicit locale environment setting on Windows (only for "outer-repo" feature using "hg root") external commands indirectly executed by "hghave" may show translated messages. This causes incorrect "hghave" result and skipping tests, because some regexp matching of "hghave" expect external commands to show un-translated messages. To prevent external commands from showing translated messages, this patch makes "run-tests.py" execute "hghave" with same environment variables as ones for actual tests. This patch doesn't make "hghave" execute external commands forcibly with LC_ALL, LANG and LANGUAGE explicitly assigned "C", because changing "run-tests.py" is cheaper than changing "hghave": - "os.popen" should be replaced by "subprocess.Popen" or so, and - setting up environment variables should be newly added

osx: use bdist_mpkg.script_bdist_mpkg module instead of bdist_mpkg command It seems like a default installation of bdist_mpkg makes it available as Python module, but the corresponding executable is placed in a location like /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/bin which is not in $PATH and thus not directly available. 'make osx' would thus fail. Instead, skip the bdist_mpkg executable and invoke it as a Python module. That works out of the box here.

osx: don't launch installer after building it with bdist_mpkg bdist_mpkg do for some reason default to use the parameter --show ("Open with Installer.app after building") if no parameters are specified. We do not like that. All the important parameters to bdist_mpkg are already specified in setup.py and we don't have any to specify in the Makefile. Instead, specify the parameter '--' which do no harm but will disable the default opening of the installer. This makes it possible to build packages "silently".

osx: update "Read Me" "Important Information" text in the package installer Nothing fancy here, just making the text less specific and less wrong by not mentioning OS X version and Python versions and wrong URLs.

commit: remove reverse search for copy source when not in parent (issue4476) Previously, we had weird, nonsensical behavior when committing a file move with a missing source. This removes that weird logic and tests that the bug this strange behavior caused is fixed. Also adds a longish comment to prevent some poor soul from accidentally re-implementing the bug in the future.

merge with i18n

i18n-pt_BR: synchronized with db8e3f7948b1

convert: handle LookupError in mercurial_source.lookuprev() This is in line with the documentation on the base class method, and is related to issue4496 (but doesn't fix the reporter's problem of not mangling other data that matches a revision pattern). Now instead of aborting when there is an ambiguous source rev, it simply won't update the commit comment. A warning message might be nice, but a None return masks whether the problem was no matching revision, or more than one. The only other caller of this is the logic that converts tags, but those are never ambiguous since they are always 40 characters. A test isn't feasible because there simply aren't enough commits in the test suite repos to have an ambiguous identifier that is at least 6 characters long, and it would be too easy for the ambiguity to disappear when unrelated changes are made. Instead, I simply ran 'hg --traceback log -r c' on the hg repo, and handled the error it threw.

color: add missing 'dim' in _effects It seems that this has been missing for people running in 'ansi' mode.

diff: use binary diff when copy source is binary When a binary source has been copied or renamed into a non-binary file, we don't check whether the copy source was binary. There is a code comment explaining that a git mode will be forced anyway in order to capture the copy record (i.e. losedatafn() will be called). This is true, but forcing git mode is not the only effect binary files have: when git mode was already requested, we use the binary-ness to tell us whether to use a regular unified diff or a git binary diff. The user sees this as a "Binary file $file has changed" instead of the binary

largefiles: fix commit of a directory with no largefile changes (issue4330) When a directory is named in the commit file list, the previous behavior was to walk the list, and if no normal files in the directory were also named, add the corresponding standin for each largefile in that directory. The directory is then dropped from the list, so that committing a directory with no normal file changes works. It then added the corresponding standin directory for the first largefile seen, by prefixing it with '.hglf/'. The latter is unnecessary since each affected largefile is explicitly referenced by its standin in the list. It also caused an abort if there were no changed largefiles in the directory, because none of its standins changed: abort: .hglf/foo/bar: no match under directory! This list of files is used to tweak a matcher in lfutil.updatestandinsbymatch(), which is what is passed to commit(). The status() call that is ultimately done in the commit code with this matcher seems to have some OS specific differences. It is not necessary to append '.' for Windows to run the largefiles tests cleanly. But if '.' is not added to the list, the match function isn't called on Linux, so status() would miss any normal files that were also in a named directory. The commit then proceeds without those normal files, or says "nothing changed" if there were no changed largefiles in the directory. This is not filesystem specific, as VFAT on Linux had the same behavior as when run on ext4. It is also not an issue with lfilesrepo.status(), since that only calls the overridden implementation when paths are passed to commit. I dont have access to an OS X machine ATM to test there. Maybe there's a better way to do this. But since the standin directory for the first largefile was previously being added, and that caused the same walk in status(), there's no preformance change to this. There is no danger of erroneously committing files in '.', because the original match function is called, and if it fails, the lfutil.updatestandinsbymatch() tweaked matcher only indicates a match if the file is in the list of standins- and '.' never is. The added tests confirm this.

test-tools: update for platforms without symlink support after 5b20e4c32117 The change was triggered by removing the 'baz' hardlink.

tests: add "(glob)" to output in test-histedit-commute.t for Windows This goes with the changes in 3831e9b3750a.

Added signature for changeset db8e3f7948b1

Added tag 3.3-rc for changeset db8e3f7948b1

merge default into stable for 3.3 feature freeze

messages: quote "hg help" hints consistently

bundle2: fix parttype enforcement As spotted by Malte Helmert.

test-tools: another vfat fix

test-tools: check for unix permissions for hardlinking

tests: more fixes for f

tests: teach f not to report symlink mode bits They're not meaningful or portable

tests: teach f not to report directory size It's not meaningful or portable

test-histedit-commute: call helper script with sh Buildbot pointed out that this test wasn't passing on Linux+vfat because there's no chmod for shell scripts.

test-tools: fix portability issues

progress: add a lock to prepare for introducing a thread

progress: move update check into helper method

progress: move current topic to member variable

progress: add try/finally to make the diffs for the next commit more readable No change in behavior.

transaction: include backup file in the "undo" transaction Once the transaction is closed, we now write transaction related data for possible future undo. For now, we only do it for full file "backup" because their were not handle at all in that case. In the future, we could move all the current logic to set undo up (that currently exists in localrepository) inside transaction itself, but it is not strictly requires to solve the current situation.

transaction: pass the name of the "undo" journal to the transaction It is time for the transaction to be responsible for setting up the undo data. It is necessary to move this logic into the transaction because many more files are handled now, and the transaction is the object tracking them all. The value can be set to None if no undo should be set.

rollback: have an empty entry for the vfsmap in rollback This empty string key is used for the store. This will be needed to properly rollback backup in a future changesets.

transaction: clarify the name of 'journal' argument for transaction The argument is a string containing the journal name (used as prefix for all other transaction file). This is not the transaction file itself. So we clarify this.

transaction: use 'util.copyfile' for creating backup Using 'copyfile' (single file) instead of 'copyfiles' (tree) will ensures destination file will be overwritten. This will prevent some abort if backup file are left in place for random reason. It also seems more correct.

copyfile: allow optional hardlinking Some code paths use 'copyfiles' (full tree) for a single file to take advantage of the best-effort-hard-linking parameter. We add similar parameter and logic to 'copyfile' (single file) for this purpose. The single file version have the advantage to overwrite the destination file if it exists.

repair: add experimental option to write bundle2 files This adds an experimental option 'strip-bundle2-version' which causes backup bundles to use bundle2 formatting. Especially for generaldelta repositories, this should provide significant performance gains for any operation that needs to write a backup.

changegroup.getsubset: support multiple versions Allow a version parameter to specify which version of the packer should be used

changegroup.writebundle: HG2Y support This diff adds support to writebundle to generate a bundle2 wrapper; upcoming diffs will add an option to write a v2 changegroup part instead of v1 in these bundles.

changegroup.writebundle: provide ui The next diff will add support for writing bundle2 files to writebundle, but the bundle2 generator wants access to a ui object. This changes the signature and callsites to pass one in.

test-module-imports: use test-repo requirement

largefiles: don't rehash largefiles in updatelfiles if standin hash changed Standins are read before and after an update/merge, and all the standins that changes are handed to updatelfiles for getting their corresponding largefiles updated. updatelfiles would then hash the largefile and see if it already matched the new expected hash. If so, it would skip the update. If different, the largefile would be updated. It would happen very rarely that the largefile happened to match the new hash (and thus not the old one) and the hashing would thus be pointless ... and hashing is not cheap. Instead, when it is known that the standin hash changed (from an update), just update the standin unconditionally. If the largefile was "unsure" before the update, it was hashed at that point, so we know there is nothing to preserve. (Also, the hashing in updatelfiles was not used to preserve changes, but only to be lazy about updating the largefile, so nothing is lost by not doing this extra hashing.) There might be rare situations where we now will update largefiles that didn't have to be updated, but in all relevant cases (?) this will improve performance. Updates on a repo with some big largefiles has been seen to go from 9.19 s to 6.8 s - that is 26% less painful.

largefiles: show progress when checking standin hashes in outgoing changesets This checking can take a huge amount of time and we should give user a hint that something is going on.

unbundle: support bundle2 files This adds support for bundle2 files to the unbundle command.

pullbundle2: extract addchangegroup result combining into its own function This will also be used for 'hg unbundle'

histedit: add a test to show that issue4251 is fixed (issue4251) This will help us not regress this case in the future.

commands.debugbundle: bundle2 support This enables debugbundle to print supporting info for bundle2 files.

largefiles: cleanup overrideadd() This was a remnant of the code prior to overridding cmdutil.add().

largefiles: enable subrepo support for add The --large, --normal and --lfsize args couldn't be passed to a subrepo before, and files in the subrepos would be added silently (if -v wasn't specified) as normal files. As an added bonus, 'hg add --dry-run' no longer prints that largefiles would also be added as normal files as well.

add: pass options via keyword args The largefiles extensions needs to be able to pass --large, --normal and --lfsize to subrepos via cmdutil.add() and hgsubrepo.add(). Rather than add additional special purpose arguments, stop extracting the existing args from the **opts passed to commands.add() and just pass them along.

largefiles: don't pop largefile-specific arguments to the add command The arguments will need to stay present when making add work with subrepos.

share: replace the bookmarks.shared file with an entry on a new "shared" file cd79fb4d75fd introduced a way to share bookmarks. When a repository share that shares bookmarks was created, a .hg/bookmarks.shared file was created to mark the repository share as one that shares its bookmarks. We have plans to introduce other levels of sharing, including a "full share" mode. Rather than creating a new ".shared" file for each new thing that we may want to share It seems better to create a single "shared" file that will list what is shared for a given shared repository. This should make it much easier to get a list of everything that is shared by a given shared repository. The shared file contains a list of shared "items" (such as bookmarks). Each shared "item" is added as a new line in the file. For now the only possible entry in the file is "bookmarks".

docker: support Fedora 21

rpm: make Python 2.7.9 the default Python to include in rpms for EL 5 Use the new and more TLS support in Python 2.7.9.

contrib: make Python 2.7.9 the default in Makefile.python We should utilize (and test) the big API changes and new TLS functionality in Python 2.7.9 whenever possible.

localrepo: remove all external users of localrepo.wopener This change touches every module in which repository.wopener was being used, and changes it for the equivalent repository.wvfs. It should now be possible to remove localrepo.wopener.

localrepo: remove all external users of localrepo.sopener This change touches every module in which repository.sopener was being used, and changes it for the equivalent repository.svfs. It should now be possible to remove localrepo.sopener.

localrepo: remove all external users of localrepo.opener This change touches every module in which repository.opener was being used, and changes it for the equivalent repository.vfs. This is meant to make it easier to split the repository.vfs into several separate vfs. It should now be possible to remove localrepo.opener.

log: use namespace logname and colorname Now that we have the machinary to change the log name and the color label used, let's use that. Tests have been updated accordingly.

namespaces: add colorname member to namespace object Previously, there was no way to change the color label used for 'hg log' output. This patch just adds the member to the object, a future patch will change 'hg log' to use this.

namespaces: add logname member to namespace object Previously, there was no way to change the name used for 'hg log' output. This was inconvenient for extensions that want a template name longer than 12 characters (e.g. remotebookmarks) but a different name for 'hg log'. This patch only adds the member to the object, a future patch will update the 'hg log' code.

namespaces: use named args for namespace api This is just a style change but makes adding new arguments more robust for callers.

namespaces: make the constructor into named args None of the arguments are truly optional but this makes adding future arguments more robust and perhaps optional.