revlog: make code in builddelta() slightly easier to read self.compress() is destructured into its components. "l" is renamed to "deltalen."

py3: update test expectation on stable

grep: rewrite help to better document current (confusing) behavior

templates: add built-in files() function We already support multiple primitive for listing files, which were affected by the current changeset. This patch adds files() which returns files of the current changeset matching a given pattern or fileset query via the "set:" prefix.

rebase: rebase changesets in topo order (issue5370) (BC) There are two reasons that rebase should be done this way: 1. This would make rebasing faster because it would minimize the total number of files to be checked out in the process, as it don't need to switch back and forth between branches. 2. It makes resolving conflicts easier as user has a better context. This commit changes the behavior in "Test multiple root handling" of test-rebase-obsolete.t. It is an expected change which reflects the new behavior that commits in a branch are grouped together when rebased.

dispatch: make hg --profile wrap reposetup Move profiling.maybeprofile() from _runcommand to _dispatch() so that profiler output will include reposetup.

dispatch: change indentation level in _dispatch() Add an if True: placeholder for a profiling context manager that will be added in the next commit, for the purpose of reducing size of the diff due to trivial indentation changes. This change should be a no-op.

log: drop outdated optimization to walk revisions in reverse order Since revset is computed lazily, there would be no (or little) benefit to reverse 'revs' temporarily.

graphlog: preserve topo sort even if additional filter options specified Use ordered=revset.followorder instead. This change is logically the same as fa5e4f58dfbc.

transaction: open a file with checkambig=True to avoid file stat ambiguity Before this patch, if steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to revlog-style file (and close transaction) 2. discard appended data by truncation of rollback 3. append same size but different data to revlog-style file again Therefore, cache validation doesn't work after (3) as expected. To avoid file stat ambiguity around truncation, this patch opens a file with checkambig=True. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

repair: open a file with checkambig=True to avoid file stat ambiguity Before this patch, if steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to revlog-style file (and close transaction) 2. discard appended data by truncation of strip 3. append same size but different data to revlog-style file again Therefore, cache validation doesn't work after (3) as expected. To avoid such file stat ambiguity around truncation, this patch opens a file with checkambig=True. This patch also introduces "with" statement style, to ensure immediate invocation of close() after truncation, because closing file is the only trigger to check (and get rid of) file stat ambiguity. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

changelog: specify checkambig=True to revlog.__init__, to avoid ambiguity If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to 00changelog.i (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to 00changelog.i again Therefore, cache validation doesn't work after (3) as expected. To avoid such file stat ambiguity around truncation, this patch specifies checkambig=True to revlog.__init__(). This makes revlog write changes out with checkambig=True. Even though changes of 00changelog.i themselves are written out at changelog._finalize(), this checkambig=True is needed, because revlog.checkinlinesize(), which is invoked at the end of changelog._finalize(), might replace already changed 00changelog.i by converted one. Even after this patch, avoiding file stat ambiguity of 00changelog.i around truncation isn't yet completed, because truncation side isn't aware of this issue. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

changelog: specify checkambig=True to avoid ambiguity around truncation If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to 00changelog.i (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to 00changelog.i again Therefore, cache validation doesn't work after (3) as expected. To avoid such file stat ambiguity around truncation, this patch specifies checkambig=True for renaming or opening to write changes out at finalization. Even after this patch, avoiding file stat ambiguity of 00changelog.i around truncation isn't yet completed, because truncation side isn't aware of this issue. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

manifest: specify checkambig=True to revlog.__init__, to avoid ambiguity If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to 00manifest.i (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to 00manifest.i again Therefore, cache validation doesn't work after (3) as expected. To avoid such file stat ambiguity around truncation, this patch specifies checkambig=True to revlog.__init__(). This makes revlog write changes out with checkambig=True. Even after this patch, avoiding file stat ambiguity of 00manifest.i around truncation isn't yet completed, because truncation side isn't aware of this issue. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

revlog: specify checkambig at writing to avoid file stat ambiguity This allows revlog-style files to be written out with checkambig=True easily. Because avoiding file stat ambiguity is needed only for filecache-ed manifest and changelog, this patch does: - use False for default value of checkambig - focus only on writing changes of index file out This patch also adds optional argument checkambig to _divert/_delay for changelog, to safely accept checkambig specified in revlog layer. But this argument can be fully ignored, because: - changes are written into other than index file, if name != target - changes are never written into index file, otherwise (into pending file by _divert, or into in-memory buffer by _delay) This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

vfs: use checkambigatclosing in checkambig=True but atomictemp=False case In Mercurial source tree, opening a file in "a"/"a+" mode like below doesn't specify atomictemp=True for vfs, and this avoids file stat ambiguity check by atomictempfile. - writing changes out in revlog layer uses "a+" mode - truncation in repair.strip() uses "a" mode - truncation in transaction._playback() uses "a" mode If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to revlog-style file (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to revlog-style file again Therefore, cache validation doesn't work after (3) as expected. This patch uses checkambigatclosing in checkambig=True but atomictemp=False case, to check (and get rid of) file stat ambiguity at closing. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

scmutil: add file object wrapper class to check ambiguity at closing In Mercurial source tree, opening a file in "a"/"a+" mode like below doesn't specify atomictemp=True for vfs, and this avoids file stat ambiguity check by atomictempfile. - writing changes out in revlog layer uses "a+" mode - truncation in repair.strip() uses "a" mode - truncation in transaction._playback() uses "a" mode If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to revlog-style file (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to revlog-style file again Therefore, cache validation doesn't work after (3) as expected. This patch adds file object wrapper class checkambigatclosing to check (and get rid of) ambiguity at closing. It is used by vfs in subsequent patch. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan BTW, checkambigatclosing is tested in test-filecache.py, even though it doesn't use filecache itself, because filecache assumes that file stat ambiguity never occurs (and there is no another test-*.py related to filecache).

scmutil: factor out common logic of delayclosedfile to reuse it This is a preparation for the subsequent patch, which adds another proxy class for a file object.

spartan: remove unused templates

monoblue: remove unused templates

gitweb: remove unused templates

paper: remove unused templates

help: add sections for revsets

help: move revsets.## documentation into infix section

help: clarify quotes are needed for filesets.size expressions

paper: remove unused template "changelogchild"

monoblue: remove unused template "changelogchild"

gitweb: remove unused template "changelogchild"

monoblue: tweak branch table's last row's cell colspan on summary page This table only has 3 columns, so max sensible colspan is 3.

gitweb: tweak branch table's last row's cell colspan on summary page This table only has 3 columns, so max sensible colspan is 3.

tests: clarify demandimport disabled state

demandimport: add trailing comma

tests: favor single quotes for wrapping hg help ...

samplehgrcs: use single quotes in use warning

util: use single quotes in use warning

obsolete: use single quotes in use warning

localrepo: use single quotes in use warning

help: use single quotes in use warning

discovery: use single quotes in use warning

serve: use single quotes in use warning

bundle: use single quotes in use warning

histedit: use single quotes in use warning

keyword: use single quotes in use warning

mq: use single quotes in use warning

pager: use single quotes in use warning

rebase: use single quotes in use warning

push: update help hint to point to config.paths section

update: use single quotes in use warning

remove: specify hg in added warning

manifest: add manifestlog.add This adds a simple add() function to manifestlog. This lets us convert more uses of repo.manifest to use repo.manifestlog, so we can further break our dependency on the manifest class.

manifest: move manifest.add onto manifestrevlog This moves add and _addtree onto manifestrevlog. manifestrevlog is responsible for all serialization decisions, so therefore the add function should live on it. This will allow us to call add() from manifestlog, which lets us further break our dependency on manifest.

manifest: remove dependency on treeinmem from manifest.add Currently manifest.add uses the treeinmem option to know if it can call fastdelta on the given manifest instance. In a future patch we will be moving add() to be on the manifestrevlog, so it won't have access to the treeinmem option anymore. Instead, let's have it actually check if the given manifest instance supports the fastdelta operation. This also means that if treemanifest or any implementation eventually implements fastdelta(), it will automatically benefit from this code path.

manifest: move treeinmem onto manifestlog A previous patched moved all the serialization related options onto manifestrevlog (since it is responsible for serialization). Let's move the treeinmem option on manifestlog, since it is responsible for materialization decisions. This reduces the number of dependencies manifestlog has on the old manifest type as well, so we can eventually make them completely independent of each other.

copy: document current behavior of 'hg cp --after' I'm about to propose an output change here, but the existing behavior was untested!

crecord: add an event that scrolls the selected line to the top of the screen Using ctrl-l for this purpose seems to be a fairly widely used practice, presumably following emacs. This doesn't scroll the selected line all the way to the top of the window, instead it leaves a 3 line buffer for context. Use curses.unctrl() to resolve keypressed to '^L' to avoid hard-coding hexadecimal key codes.

log: drop hack to fix order of revset (issue5100) Specify ordered=revset.followorder instead. This patch effectively backs out c407583cf5f6. revs.sort(reverse=True) is replaced by revs.reverse() because the matcher should no longer reorder revisions.

revset: add option to make matcher takes the ordering of the input set This allows us to evaluate match(subset) as if 'subset & expr', which will be the complete fix for the issue5100.

strip: don't use "full" and "partial" to describe bundles The partial bundle is not a subset of the full bundle, and the full bundle is not full in any way that i see. The most obvious interpretation of "full" I can think of is that it has all commits back to the null revision, but that is not what the "full" bundle is. The "full" bundle is simply a backup of what the user asked us to strip (unless --no-backup). The "partial" bundle contains the revisions we temporarily stripped because they had higher revision numbers that some commit that the user asked us to strip. The "full" bundle is already called "backup" in the code, so let's use that in user-facing messages too. Let's call the "partial" bundle "temporary" in the code.

strip: clarify that user action is required to recover temp bundle If strip fails when applying the temporary bundle, the commits in the temporary bundle have not yet been applied, so the user will almost definitely want to apply the bundle. We should be more clear to the user about that than our current "partial bundle stored in...". Note that we will probably not be able to recover it automatically, since whatever made it fail (e.g. a hook) will most likely make it fail again. We need to give control back to the user to fix the problem before trying again.

strip: report both bundle files in case of exception (issue5368) If strip fails while recovering the temporary bundle (e.g. because a hook fails), we tell the user only about the backup bundle, not about the temporary bundle. Since the user did not ask to strip the commits in the temporary bundle, that's the more important bundle to mention, so let's do that (and also mention the backup bundle as usual).

strip: simplify some repeated conditions We check "if saveheads or savebases" in several places to see if we should or have created a bundle of the changesets to apply after truncating the revlogs. One of the conditions is actually just "if saveheads", but since there can't be savebases without saveheads, that is effectively the same condition. It seems simpler to check only once and from then on see if we created the file.

config: add template support V2: - Limit escaping to plain formatting only - Use the formatter consistently (no more ui.debug) - Always include 'name' and 'value' V3: - Always convert 'value' to string (this also makes sure we handle functions) - Keep real debug message as ui.debug for now - Add additional tests. Note: I'm not quite sure about the best approach to handling the 'print the full config' case. For me, it printed the 'ui.promptecho' key at the end. I went with globs there as that at least tests the json display reliably. Example output: [ { "name": "ui.username", "source": "/home/mathias/.hgrc:2", "value": "Mathias De Maré <mathias.demare@gmail.com>" } ]

formatter: introduce isplain() to replace (the inverse of) __nonzero__() (API) V2: also remove and replace __nonzero__

diffopts: notice a negated boolean flag in diffopts This means that if you have git-diffs enabled by default (pretty common) and you hit the rare (but real) case where a git-diff breaks patch(1) or some other tool, you can easily disable it by just specifying --no-git on the command line. I feel a little bad about the isinstance() check, but some values in diffopts are not booleans and so we need to preserve false iff the flag is a boolean flag: failing to do this means we end up with empty string defaults for flags clobbering meaningful values from the [diff] section in hgrc.

flags: allow specifying --no-boolean-flag on the command line (BC) This makes it much easier to enable some anti-foot-shooting features (like update --check) by default, because now all boolean flags can be explicitly disabled on the command line without having to use HGPLAIN or similar. Flags which don't deserve this treatment can be removed from consideration by adding them to the nevernegate set in fancyopts. This doesn't make it any easier to identify when a flag is set: opts still always gets filled in, either with the user-specified flag value or with the default from the flags list in the command table. Improving that would probably clean things up a bit, but for now if you want a boolean flag and care if it was explicitly false or default false (or true, but nobody uses that functionality because before now it was nonsense) you need to use None as your default rather than True or False. This doesn't (yet) update help output, because I'm not quite sure how to do that cleanly.

revset: make sort() noop depending on ordering requirement (BC) See the previous patch for why.

revset: make reverse() noop depending on ordering requirement (BC) Because smartset.reverse() may modify the underlying subset, it should be called only if the set can define the ordering. In the following example, 'a' and 'c' is the same object, so 'b.reverse()' would reverse 'a' unexpectedly. # '0:2 & reverse(all())' <filteredset <spanset- 0:2>, # a <filteredset # b <spanset- 0:2>, # c <spanset+ 0:9>>>

revset: fix order of nested 'range' expression (BC) Enforce range order only if necessary as the comment says "carrying the sorting over would be more efficient."

revset: forward ordering requirement to argument of present() present() is special in that it returns the argument set with no modification, so the ordering requirement should be forwarded. We could make present() fix the order like orset(), but that would be silly because we know the extra filtering cost is unnecessary.

crecord: delete commented line

manifest: move dirlog up to manifestrevlog This removes dirlog and its associated cache from manifest and puts it in manifestrevlog. The notion of there being sub-logs is specific to the revlog implementation, and therefore belongs on the revlog class. This patch will enable future patches to move the serialization logic for manifests onto manifestrevlog, which will allow us to move manifest.add onto manifestlog in a way that it just calls out to manifestrevlog for the serialization.

manifest: move revlog specific options from manifest to manifestrevlog The manifestv2 and treeondisk options are specific to how we serialize the manifest into revlogs, so let's move them onto the manifestrevlog class. This will allow us to add a manifestlog.add() function in a future diff that will rely on manifestrevlog to make decisions about how to serialize the given manifest to disk. We have to move a little bit of extra logic about the 'dir' as well, since it is used in conjunction with the treeondisk option to decide the revlog file name. It's probably good to move this down to the manifestrevlog class anyway, since it's specific to the revlog.

manifest: adds manifestctx.readfast This adds a copy of manifest.readfast to manifestctx.readfast and adds a consumer of it. It currently looks like duplicate code, but a future patch causes these functions to diverge as tree concepts are added to the tree version.

manifest: add manifestctx.readdelta() This adds an implementation of readdelta to the new manifestctx class and adds a couple consumers of it. This currently appears to have some duplicate code, but future patches cause this function to diverge when things like "shallow" are introduced.

merge with stable

rebase: make debug logging more consistent We emit some lines that mix revision numbers with nodeids, which makes little sense to me.

revset: fix order of nested '_(|int|hex)list' expression (BC) This fixes the order of 'x & (y + z)' where 'y' and 'z' are trivial, and the other uses of _list()-family functions. The original functions are renamed to '_ordered(|int|hex)list' to say clearly that they do not follow the subset ordering.

revset: fix order of nested 'or' expression (BC) This fixes the order of 'x & (y + z)' where 'y' and 'z' are not trivial. The follow-order 'or' operation is slower than the ordered operation if an input set is large: #0 #1 #2 #3 0) 0.002968 0.002980 0.002982 0.073042 1) 0.004513 0.004485 0.012029 0.075261 #0: 0:4000 & (0:1099 + 1000:2099 + 2000:3099) #1: 4000:0 & (0:1099 + 1000:2099 + 2000:3099) #2: 10000:0 & (0:1099 + 1000:2099 + 2000:3099) #3: file("path:hg") & (0:1099 + 1000:2099 + 2000:3099) I've tried another implementation, but which appeared to be slower than this version. ss = [getset(repo, fullreposet(repo), x) for x in xs] return subset.filter(lambda r: any(r in s for s in ss), cache=False)

revset: add 'takeorder' attribute to mark functions that need ordering flag Since most functions shouldn't need 'order' flag, it is passed only when explicitly required. This avoids large API breakage.

revset: pass around ordering flags to operations Some operations and functions will need them to fix ordering bugs.

revset: add stub to handle parentpost operation All operations will take 'order' flag, but p1() function won't.

revset: infer ordering flag to teach if operation should define/follow order New flag 'order' is the hint to determine if a function or operation can enforce its ordering requirement or take the ordering already defined. It will be used to fix a couple of ordering bugs, such as: a) 'x & (y | z)' disregards the order of 'x' (issue5100) b) 'x & y:z' is listed from 'y' to 'z' c) 'x & y' can be rewritten as 'y & x' if weight(x) > weight(y) (a) and (b) are bugs of the revset core. Before this, there was no way to tell if 'orset()' and 'rangeset()' can enforce its ordering. These bugs could be addressed by overriding __and__() of the initial set to take the ordering of the other set: class fullreposet: def __and__(self, other): # allow other to enforce its ordering return other but it would expose (c), which is a hidden bug of optimize(). So, in either ways, optimize() have to know the current ordering requirement. Otherwise, it couldn't rewrite expressions by weights with no output change, nor tell how a revset function or operation should order the entries. 'order' is tri-state. It starts with 'define', and shifts to 'follow' by 'x & y'. It changes back to 'define' on function call 'f(x)' or function-like operation 'x (f) y' because 'f' may have its own ordering requirement for 'x' and 'y'. The state 'any' will allow us to avoid extra cost that would be necessary to constrain ordering where it isn't important, 'not x'.

revset: wrap arguments of 'or' by 'list' node This makes the number of 'or' arguments deterministic so we can attach additional ordering flag to all operator nodes. See the next patch. We rewrite the tree immediately after chained 'or' operations are flattened by simplifyinfixops(), so we don't need to care if arguments are stored in x[1] or x[1:].

journal: properly check for held lock (issue5349) The 'jlock' code meant to check for a held lock, but it actually just checking for a lock object. With CPython, this worked because the 'jlock' object is not referenced outside the '_write' function so reference counting would garbage collect it and the '_lockref' would return None. With pypy, the garbage collection would happen at an undefined time and the '_lockref' can still point to a 'jlock' object outside of '_write'. The right thing to do here is not only to check for a lock object but also to check if the lock is held. We update the code to do so and reuse a utility method that exist on 'localrepo' to help readability. This fix journal related tests with pypy.

ssl: handle a difference in SSLError with pypy (issue5348) The SSLError exception is a bit different with pypy (message is the first argument, not the second) This led the certificate error handling to crash when trying to extract the ssl error message. We now handle this different and 'test-https.t' is green again.

manifest: change manifestctx to not inherit from manifestdict If manifestctx inherits from manifestdict, it requires some weird logic to lazily load the dict if a piece of information is asked for. This ended up being complicated and unintuitive to use. Let's move the dict creation to .read(). This will make even more sense once we start adding readdelta() and other similar methods to manifestctx.

manifest: make one use of _mancache avoid manifestctxs In a future patch we will change manifestctx and treemanifestctx to no longer derive from manifestdict and treemanifest, respectively. This means that consumers of the _mancache will now need to be aware of the different between the two, until we get rid of the manifest entirely and the _mancache becomes only filled with ctxs. This fixes one case of it that can be fixed by using the other cache. Future patches will address the others uses using the upcoming manifestctx.read() function.

debugrevspec: add option to verify optimized result This provides a convenient way to diff "hg debugrevspec" outputs generated with/without --no-optimized option.

debugrevspec: add option to skip optimize() and evaluate unoptimized tree This will help debugging optimizer bugs. Maybe '--no-optimized' can be changed to '--optimized' (default: True) when flags series landed.

revset: remove showwarning option from expandaliases() Now all callers pass showwarning=ui.warn, so we no longer need the option to suppress warnings.

debugrevspec: evaluate tree built by itself Prepares for new option to evaluate an unoptimized tree. Since a revset expression is no longer parsed twice, alias warnings should be displayed at the first parsing stages. That's why showwarning=ui.warn is added.

localrepo: make _refreshfilecachestats unfiltered method to refresh correctly Before this patch, if transaction is started via "filtered repo" object, _refreshfilecachestats() at closing transaction doesn't refresh file stat of any @filecache properties correctly, because: - _refreshfilecachestats() omits refreshing file stat of a @filecache property, if it doesn't appear in self.__dict__ - if transaction is started via "filtered repo", _refreshfilecachestats() is applied on "filtered repo" because repo.transaction() adds "self._refreshfilecachestats" to post close procedures. repo.transaction() isn't unfiltered method, and "self" in it means "filtered repo" in this case. Transactions started by explicit repo.transaction() easily causes this situation. - _refreshfilecachestats() applied on "filtered repo" omits whole refreshing because @filecache properties are stored into "unfiltered repo", and appear only in self.__dict__ of "unfiltered repo". This incorrect refreshing causes unnecessary reloading from files. To refresh file stat of @filecache properties at closing transaction correctly, this patch makes _refreshfilecachestats() unfiltered method. This patch chooses making _refreshfilecachestats() unfiltered method instead of making transaction() unfiltered method, to reduce unexpected side effect.

streamclone: clear caches after writing changes into files for visibility Before this patch, streamclone-ed changes are invisible via @filecache properties to in-process procedures before closing transaction (e.g. pretxnclose python hook), if corresponded property is cached before consumev1(). Strictly speaking, caching should occur inside (store) lock for transaction. repo.invalidate() after closing transaction is too late to force @filecache properties to be reloaded from changed files at next access. For visibility of streamclone-ed changes to in-process procedures before closing transaction, this patch clears caches just after writing changes into files. BTW, regardless of changing in this patch, clearing cached properties in consumev1() causes inconsistency, if (1) transaction is started and (2) any @filecache property is changed before consumev1(). This patch also adds the comment to fix this (potential) inconsistency in the future.

localrepo: make invalidate avoid invalidating store inside transaction (API) Before this patch, invalidate() discards in-memory fncache changes, even inside transaction scope. Such changes should be written out at closing transaction. Otherwise, fncache might overlook newly added files. A file overlooked by fncache isn't accessible via store vfs, even if it actually exists in store. On the other hand, a non-existing file in fncache is less harmful, because fncachestore always examines whether a file actually exists or not before access. Therefore, discarding in-memory changes can be safely omitted. It is typical case that repo.invalidate() in streamclone is executed inside nested transaction. This patch makes invalidate() avoid invalidating store inside transaction. This patch focuses on describing only how invalidate() changes own behavior according to activity of transaction. Describing other detail of invalidate() in docstr will be done in another series, which refactors invalidate*() functions.

streamclone: force @filecache properties to be reloaded from file Before this patch, consumev1() invokes repo.invalidate() after closing transaction, to force @filecache properties to be reloaded from files at next access, because streamclone writes data into files directly. But this doesn't work as expected in the case below: 1. at closing transaction, repo._refreshfilecachestats() refreshes file stat of each @filecache properties with streamclone-ed files This means that in-memory properties are treated as valid. 2. but streamclone doesn't changes in-memory properties This means that in-memory properties are actually invalid. 3. repo.invalidate() just forces to examine file stat of @filecache properties at the first access after it Such examination should concludes that reloading from file isn't needed, because file stat was already refreshed at (1). Therefore, invalid in-memory cached properties (2) are unintentionally treated as valid (1). This patch invokes repo.invalidate() with clearfilecache=True, to force @filecache properties to be reloaded from file at next access. BTW, it is accidental that repo.invalidate() without clearfilecache=True in streamclone case seems to work as expected before this patch. If transaction is started via "filtered repo" object, repo._refreshfilecachestats() tries to refresh file stat of each @filecache properties on "filtered repo" object, even though all of them are stored into "unfiltered repo" object. In this case, repo._refreshfilecachestats() does nothing unintentionally, but this unexpected behavior causes reloading @filecache properties after repo.invalidate(). This is reason why this patch should be applied before making _refreshfilecachestats() correctly refresh file stat of @filecache properties.

manifest: backed out changeset bb3281b3fcaa There is some suspicious failure in evolution tests. This changeset was supposed to be dropped until we investigate.

manifest: backed out changeset b60a5fe98b73 There is some suspicious failure in evolution tests. This changeset was supposed to be dropped until we investigate.

debugrevspec: deprecate --optimize option This option has been superseded by '--show-stage NAME', and will cause confusion in future patches.

debugrevspec: add option to print parsed tree at given stages "-p <stage>" is useful for investigating parsing stages. With -p option, a transformed tree is printed no matter if it is changed or not, which allows us to know valid stage names by "-p all".

debugrevspec: transform and print parsed tree by stages Prepares for adding new option to print transformed tree at each stage.

debugrevspec: build parsed tree even if no --verbose specified Prepares for evaluating unoptimized tree. The output is suppressed by ui.note() anyway.

osutil: fix the declaration to work on different sizes of off_t

manifest: change manifestctx to not inherit from manifestdict If manifestctx inherits from manifestdict, it requires some weird logic to lazily load the dict if a piece of information is asked for. This ended up being complicated and unintuitive to use. Let's move the dict creation to .read(). This will make even more sense once we start adding readdelta() and other similar methods to manifestctx.

manifest: make uses of _mancache aware of contexts In a future patch we will change manifestctx and treemanifestctx to no longer derive from manifestdict and treemanifest, respectively. This means that consumers of the _mancache will now need to be aware of the different between the two, until we get rid of the manifest entirely and the _mancache becomes only filled with ctxs.

manifest: add treemanifestctx class Before we start using repo.manifestlog in the rest of the code base, we need to make sure that it's capable of returning treemanifests. As we add new functionality to manifestctx, we'll add it to treemanifestctx at the same time. We also comment out the manifestctx p1, p2, and linkrev fields for now, since we're not implementing them on treemanifest yet.

revset: add public function to create matcher from evaluatable tree "hg debugrevspec" will use it to evaluate unoptimized tree.

revset: make analyze() a separate step from optimize() This will allow us to evaluate unoptimized tree and compare the result with optimized one. The private _analyze() function isn't renamed since I'll add more parameters to it.

revset: extract tree transformation from optimize() This patch separates the simple tree transformation from the optimization step, which is called as _analyze() since I'll extend this function to infer ordering flags. I want to avoid making _optimize() more complicated. This will also allow us to evaluate unoptimized tree.

hghave: fix has_bzr() to not try to import RevisionSpec as module Since RevisionSpec isn't a module, "import bzrlib.revisionspec.RevisionSpec" would always raise ImportError.

update: label bookmark name in message We label bookmark name as such in various messages. This will help them to standout (or at least give the user the option to make them stand out). We use a distinct label for the 'active' bookmark, this can help users to catch bookmark operation affecting their working copy.

discovery: explicitly check for None in outgoing init f09d0004481c introduced default params for discovery.outgoing(), but it used a falsy check instead of an explicit check for None. The result is that callers that passed in an empty list would have that list overridden by the defaults, which is not the expected behavior. This was discovered by changes to the test-pushrebase.t test in Facebook's repository of mercurial extensions.

import: report directory-relative paths in error messages (issue5224) Import uses paths relative to the root of the repository, so when user imports patch with paths relative to the current working directory import aborts with 'unable to find file for patching'. This patch improves this situation by warning the user that paths are relative to the root of repository when patching fails.

commands: remove unecessary copying of list in graft()

revset: do not partial-match operator and function names in optimize() It was error-prone, and actually there was a typo, s/ancestorspec/ancestor/.

revset: remove false condition to process 'negate' operator 'negate' is mapped to 'string' at the above clause.

revset: make optimize() reject unknown operators This should have caught the bug of 'keyvalue' operator fixed at 5004ef47f437. The catch-all pattern is useless since optimize() should be aware of all known operators.

help: show content for explicitly disabled extension (issue5228)

obsolete: fix minor module documentation issues

debugextensions: hide "ships-with-hg-core" magic string (BC) Since we have "bundled" flag, we no longer need to rephrase "ships-with-hg-core" to show as "internal".

debugextensions: show ships-with-hg-core state as a separate field This is less magical than rephrasing ships-with-hg-core as internal, and we can distinguish "internal" liar. "tested with: internal" will be hidden by the next patch.