test-bookmarks-pushpull.t: don't set bookmark active unnecessarily The test in question doesn't have anything to do with having an active bookmark. This change makes the test change the two bookmarks it affects without making them active. It clears the way for adding a test for updating to an active bookmark that moved out from under us.

doc: use "tag" revset predicate instead of "tagged" for example in help "tag" predicate is officially described in help, but "tagged" is not, even though the latter works as same as the former.

tests: add regression tests for another revrange edge case These tests would've passed before ac0c12123743 and e441657b372b. Inserting them to make sure that continues to be the case.

graphmod: don't try to visit nullrev (issue3772)

log: remove any ancestors of nullrev (issue3772) For the special case, ":null" we remove the implied revision 0 since that wouldn't make any sense here. A test case is added to make sure only nullrev is shown.

help: add documentation for new template functions

changectx: fix the handling of `tip` We can not use `len(repo,changelog)`, it may be a filtered revision. We now use `repo,changelog.tip()` to fetch this information. The `tip` command is also fixed and tested Thanks goes to Idan Kamara for the initial report.

bisect: use changelog for iteration With changelog filtering, we can not use xrange anymore. We have to use the changelog to do the iteration. This way, the changelog excludes filtered revision and we can safely use what we iterate over. Without this changes, bisect crash with a traceback if there is filtered revision in the repo. Tests have been updated.

documentation: update to new filter names Changeset f3b21beb9802 change filter names but forgot some documentation updates.

largefiles: enhance error message to make it more i18n-friendly

merge with i18n

largefiles: fix largefiles+subrepo update (issue3752) Override updaterepo() instead of individual methods that may not be called for each subrepo. Add test. Based on patch from Matt Harbison. Changes the order of update-related messages (now largefiles comes before the global status).

debugsuccessorssets: fix typos in docstring

i18n-pt_BR: synchronized with f5fbe15ca744

merge: only sort manifests in debug mode (issue3769)

Added signature for changeset f5fbe15ca744

Added tag 2.5-rc for changeset f5fbe15ca744

merge default into stable for 2.5 code freeze

pathencode: don't use alloca() for safety/portability

branchmap: display filtername when `updatebranch` fails to do its jobs We have a very handy assert at the ends of `branchmap.updatecache` that check the resulting branchmap is actually valid. I know we do not like assert in mercurial but this one is very handy for debugging. There is really not reason for `branchmap.updatecache` to have this kind of issue but this happened and handful of time during the development of this or introduction of other related feature. I advice to keep it around until we are a bit more confident with the new code.

scmutil: localize and improve 'not under root' message

run-tests.py: don't let hg run interactively in debug mode In normal test mode stdin is closed and hg is thus not interactive. In --debug mode stdin is inherited from the running console and to the tests, and hg could thus wait in prompts when running on Windows. See http://selenic.com/pipermail/mercurial-devel/2013-January/047548.html . Instead set ui.interactive=False to make Mercurial non-interactive. Other commands might still work differently in the --debug environment. This should solve the problem with hg waiting for input but still make it possible to add --debugger to hg in a test and run run-tests.py with --debug.

run-tests.py: backout "don't use console for stdin when running in debug mode" f5842787a958 caused that some kind of interactive debugging no longer was possible - such as running hg with --debugger in a test run with run-tests.py --debug .

rebase: properly handle unrebased revision between rebased one With rebase taking multiple roots it is possible to have revision in the "rebase domain" not rebased themself. We do not want rebased revision above them to be detached. We want such revision to be rebased on the nearest rebased ancestors. This allows to preserve the topology of the rebase set as much a possible To achieve this we introduce a new state `revignored` which informs `defineparents` of the situation. The test in `test-rebase-obsolete.t` was actually wrote and his now fixed.

rebase: lose the comparison to `nullmerge` For a proper behavior of the `--rev` revision we will need another possible state for revision ignored by rebase. We alter the comparison to `nullmerge` to match this future lower state too.

repoview: cache filtered changelog Creating a new changelog object for each access is costly and prevents efficient caching changelog side. This introduced a x5 performance regression in log because chunk read from disk were never reused. We were jumping from about 100 disk read to about 20 000. This changeset introduce a simple cache mechanism that help the last changelog object created by a repoview. The changelog is reused until the changelog or the filtering changes. The cache invalidation is much more complicated than it should be. But MQ test show a strange cache desync. I was unable to track down the source of this desync in descent time so I'm not sure if the issue is in MQ or core. However given the proximity to the 2.5 freeze, I'm choosing the inelegant but safe route that makes the cache mechanism safer.

rebase: do not invent successor to skipped changeset When rebase results in an empty a changeset it is "skipped" and no related changeset is created at all. When we added obsolescence support to rebase (in fc2a6114f0a0) it seemed a good idea to use its parent successor as the successors for such dropped changesets. (see old version of the altered test). This option was chosen because it seems a good way to hint about were the dropped changeset "intended" to be. Such hint would have been used by automatic evolution mechanism to rebase potential unstable children. However, field testing of this version are not conclusive. It very often leads to the creation of (totally unfounded) evolution divergence. This changeset changes this behavior and mark skipped changesets as pruned (obsolete without successors). This prevents the issue and seems semantically better probably a win for obsolescence reading tool. See example bellow for details: User Babar has five changesets of interest: - O, its current base of development. - U, the new upstream - A and C, some development changesets - B another development changeset independent from A O - A - B - C \ U Babar decides that B is more critical than the A and C and rebase it first $ hg rebase --rev B --dest U B is now obsolete (in lower case bellow). Rebase result, B', is its successors.(note, C is unstable) O - A - b - C \ U - B' Babar is now done with B', and want to rebase the rest of its history: $ hg rebase --source A --dest B' hg rebase process A, B and C. B is skipped as all its changes are already contained in B'. O - U - B' - A' - C' Babar have the expected result graph wise, obsolescence marker are as follow: B -> B' (from first rebase) A -> A' (from second rebase) C -> C' (from second rebase) B -> ?? (from second rebase) Before this changeset, the last marker is `B -> A'`. This cause two issues: - This is semantically wrong. B have nothing to do with A' - B has now two successors sets: (B',) and (A',). We detect a divergent rewriting. The B' and A' are reported as "divergent" to Babar, confusion ensues. In addition such divergent situation (divergent changeset are children to each other) is tricky to solve. With this changeset the last marker is `B -> ø`: - This is semantically better. - B has a single successors set (B',) This scenario is added to the tests suite.

repoview: protect `base` computation from weird phase root If for some reason the phase roots contains nullid, the set of filtered revs will contains -1. That confuse Mercurial a lot. In particular this corrupt the branchcache. Standard code path does not result in nullid phase root. It can only result from altered `.hg/store/phaseroots` or buggy extension. However better safe than sorry.

posix: don't compare atime when determining if a file has changed A file's atime might change even if the file itself doesn't change. This might cause us to invalidate caches more often than necessary. Before this change, hg add often resulted in the dirstate being parsed twice on systems that track atime. After this change, it is only parsed once. For a repository with over 180,000 files, this speeds up hg add from 1.2 seconds to 1.0.

hg: replace DirCleanup class with normal try/finally use

histedit: proper phase conservation (issue3724) Before this changeset, histedit created all new changesets according phases.new-commit option without any regards for the phases of the original changesets. This changeset fix that using the phase of rewritten changeset to decide the phase of the resulting changeset. In case of reordering or folding, we keep secret item secret as it seems the safer path. temporary commit creation are not affected. They are head only and stripped at the end of the histedit. As for the resolution of issue3681 (obsolescence cycle prevention), we do not handle changesets created by edit command.

test-histedit: reorder phases test and prepare for more We are going to add a lot regarding phase of test while fixing issue3724. This movement allows to put them after this first phase test.

test-histedit: fix instability creation test The current test does not rewrite anything and therefor does not create any instability. We also clean up the repo state after the test. This required the rebase extension.

histedit: record histedit source (issue3681) Have histedit record the hex of the original changeset as already done by: - graft - commit --amend - rebase My main motivation for adding this is to prevent the creation of obsolescence cycle (see issue3681). Note that commit created during edit are not affected yet.

histedit: factor most commit creation in a function Later commits add two important items to histedit: - Obsolescence cycle prevention - Proper phase conservation Those logics must be applied to all simple operations (pick, edit, mess) and will require verbose code. So we introduce a new function that will provide an entry point for this new. logic. The function build a closure to have a clear distinction between commit arguments and data provided to the function to fulfil its logic.

store: switch to C-based hashed path encoding

pathencode: implement both basic and hashed encoding in C

pathencode: implement hashed encoding in C This will be used by an upcoming patch.

pathencode: implement the "mangling" part of hashed encoding in C This will be used by an upcoming patch.

pathencode: add a SHA-1 hash function This will be used by an upcoming patch. This calls out to the Python hash implementation. An earlier version of this function implemented SHA-1 directly, but the amount of extra code didn't seem like a good tradeoff compared to the small big-picture increase in performance (long paths are uncommon).

store: implement lowerencode in C

hgweb: run with "served" filter This changeset enable the "served" filter on all repo used by hgweb. Hgweb misbehave in a lot of when filtering changeset are present but I do not expect normal people to have secret or obsolete changeset on they server. Misbehavior will be gradually fixed later.

hgweb: walk the graph through the changelog This is necessary to enforce filtering. The result is a bit buggy (may provide less changeset than expected, but it will stop crashing on filtered revision access. Note that changelog.revs can not represents empty iteration like xrange did. So we have to explicitly prevent call when there is nothing to do.

hgweb: use changelog for iteration Iterating through changelog is necessary to enforce filtering.

hgweb: ignore filtered revision in revnav This changeset checks that a revision is known before adding it to the navigation. This will prevent traceback on filtered repository. This changeset result in an incorrect behaviors, Navigation link may be dropped without any replacement. However this bad navigation generation is much better than a crash

hgweb: generate revnav in two phase We first generate revision to link. Then we dispatch them in before, after list. This will help filtering of unknown revision.

rebase: support multiple roots for rebaseset We have all the necessary mechanism to rebase a set with multiple roots, we only needed a proper handling of this case we preparing and concluding the rebase. This changeset des that. Rebase set with multiple root allows some awesome usage of rebase like: - rebase all your draft on lastest upstream hg rebase --dest @ --rev 'draft()' - exclusion of specific changeset during rebase hg rebase --rev '42:: - author(Babar)' - rebase a set of revision were multiple roots are later merged hg rebase --rev '(18+42)::'

clfilter: stronger detection of filtered changeset in changectx.__init__ We previously let some IndexError spill out of this function. A new tests is added to check the command that spotted the error.

validate: check for spurious incoming filelog entries Accepting those will lead to "mild corruption", correctly reported as an error by hg verify, but often not a problem in practice. Enabled when server.validate is switched on.

zsh_completion: add descriptive branch names to head revisions

zsh_completion: add completion of branch names

zsh_completion: fix issue with overlong branch/tag names

bundlerepo: remove old style check of file names The old check is no longer needed: The checked paths will be passed on to filelog.__init__ which will prefix the path with 'data/'. A leading '/' will thus not do any harm. And: The paths will be used by an opener which will use a pathauditor. And finally: The old check did not consider Windows paths and was thus insufficient.

bundlerepo: use revlog._checkhash The error message will mention datafile instead of indexfile.

bundlerepo: store validated deltabase rev in basemap instead of node This avoids some lookups and aligns bundlerepo more with what revlog do.

bundlerepo: use rev instead of node for iteration in revision() Avoids some lookups and avoids using rev while iterating.

bundlerepo: inline inbundle() It didn't make it faster, it didn't make the code smaller, it didn't make the code simpler. -1 is never in basemap.

bundlerepo: drop bundlebase wrapper function for basemap

bundlerepo: remove unused disktiprev attribute

bundlerepo: improve performance for bundle() revset expression Create the set of revision numbers directly instead of creating a list of nodes first.

bundlerepo: fix outdated comment Comment was made invalid by 01ee43dda681.

hgweb: pass repo object to revnav construction For compatibility with changelog filtering we need access to the changelog, a simple nodefunc is not sufficient, only the changelog and repo have access the filteredrevs information. For the filerevnav version, we use an unfiltered changelog. Linkrev is currently broken with filtering and we need some failsafe to prevent traceback. This is the same approach as the one used in 518c1403838f. The use of filectx.changectx() allowed the previous code to use the 518c1403838f hack. This changeset may result in an incorrect behaviors, Navigation link may point to missing revision. However this bad navigation generation is much better than a plain crash

hgweb: introduction a filerevnav subclass It'll be use to implement the file specific behavior.

hgweb: simplify addition of "(0) navigation entry"

hgweb: simplify the handling of empty repo This abstraction have two advantages: - If the revlog is empty, None of the code bellow is relevant, early returns seems a win. - Abtraction of the 'emptiness' check will help later when we stop relying on nodefunc. A bonus, with filtering, a non-empty revlog may not have '0' revision accessible. It'll be easier to handle with the emptiness test in a dedicated function

hgweb: move hex creation into an object method This is clearer and allow later overwrite.

hgweb: pass nodefunc to the revnav object The issue between hgweb and filtering lay in this function. Moving it into the object itself helps to abstract the erroneous bit.

hgweb: move revnavgen into an object For later compatibility with changelog filtering some part of the navigation generation logic will be altered. Those altered part will be different when in the changelog case and in the filelog case. Moving this into an object will allow to use inheritance to override just the part of the logic we need. The aimed logic are for example: - generation of revision 'hex' (different logic for changelog and filelog) - revlog emptyness test - fetching of the first revision of a revlog (may not be 0)

hgweb: `limit` argument is actually `latestonly` renames and enforce The `limit` argument of several generator have only two possible values in practice: 0 and 1. We rename this parameter to `latestonly` and simplify it's handling. The simplification allows us to save fetching of data that we are sure to not consume. Having a function minimal function perimeter will helps future refactoring.

hgweb: add test regarding filtering and hgweb Since 4d1671b39168 hgweb is broken with filtering. This changeset add test that should pass once it is fixed. Test currently broken are commented and will be uncommented by changeset that fix them. The filelog test is currently passing because we already have some hack in core regarding filelog (see 518c1403838f).

get-with-headers: add a --headeronly switch In some case we do not care about the actual rendering.

tests: more comment cleanup related to obsolescence

test: fix in-test comments related to obsolescence The `ui.prevent-unstable` option never made it into core. It always behaves this way when obsolescence feature is enabled. See changesets c5bd753c5bc6, bacf55bd8f90 and 0f5a0a2073a8 for details.

stream_in: write the remote branchcache for a usage as wide as possible Writing cache for unfiltered repo only is barely useful, Most repo user are now at least use the `hidden` filter. This changeset now assigns the remote cache for a filter as low as possible for a wider reuse as possible.

destroyed: update `unserved` branchcache instead Before this changesets the `destroyed` function updated the branchcache for unfiltered repository. As seen in a previous changeset, Read only repo does not cares about the unfiltered repo. We now update it for `unserved`.

destroyed: drop complex branchcache rebuilt logic The strip code used a trick to lower the cost of branchcache update after a strip. However is less necessary since we have branchcache collaboration. Invalid branchcache are likely to be cheaply rebuilt again a near subset of the repo. Moreover, this trick would need update to be relevant in the now filtered repository world. It currently update the unfiltered branchcache that few people cares about. Make it smarter on that aspect would need complexes update of the calling logic So this mechanism is: - Arguably needed, - Currently irrelevant, - Hard to update and I'm dropping it. We now update the branchcache in all case by courtesy of the read only reader. This changeset have a few expected impact on the testsuite are different cache are updated.

branchmap: update cache of 'unserved' filter on new changesets The `commitctx` and `addchangegroup` methods of repo upgrade branchcache after completion. This behavior aims to keep the branchcache in sync for read only process as hgweb. See ee317dbfb9d0 for details. Since changelog filtering is used, those calls only update the cache for unfiltered repo. One of no interest for typical read only process like hgweb. Note: By chance in basic case, `repo.unfiltered() == repo.filtered('unserved')` This changesets have the "unserved" cache updated instead. I think this is the only cache that matter for hgweb. We could imagine updating all possible branchcaches instead but: - I'm not sure it would have any benefit impact. It may even increase the odd of all cache being invalidated. - This is more complicated change. So I'm going for updating a single cache only which is already better that updating a cache nobody cares about. This changeset have a few expected impact on the testsuite are different cache are updated.

tests: make test-hgweb.t output stable Instability introduced in combination of a4d7fd7ad1f7 and e389a25e7e60.

hgweb: ensure _navseq yield strictly increasing numbers This is not hard and allows to drop hack in the customer code.

hgweb: better names for _navseq arguments The old names were misleading.

hgweb: drop recursivity in _navseq This is totally not needed.

hgweb: move the `seq` function out of the revnavgen scope There is not reason for it to be a in there. And this function could use a major reworks.

hgweb: simplify return value creation in for navgen We now have access to better syntax allowing a clearer version.

hgweb: do not access first changeset with a string There is not reason not to use an int

refactoring: use unlinkpath with ignoremissing

docs: "deprecate" checkchanged and checkconflicts in merge-tool configuration These settings were replaced by check=changed and check=conflicts in a912f26777d3. There is no reason to announce two different ways to achieve the same. The old way should be kept but not announced.

tests: run with PYTHONHASHSEED=random Python set and dict iteration order is in principle undefined but usually 'quite stable'. Setting PYTHONHASHSEED=random will make the iteration order more random in Python 2.6.8 and 2.7.3 and where it has been backported. This can thus help spot dependencies on undefined behaviour and prevent future problems.

run-tests: exit cleanly if parallel run is interrupted If interrupted while running with "--jobs N", run-tests asynchronously spewed a bunch of output and backtraces from both the master and slave processes, leaving the terminal full of goop. This patch makes it behave more sensibly.

filtering: rename filters to their antonyms Now that changelog filtering is in place, it's become evident that naming the filters according to the set of revs _not_ included in the filtered changelog is confusing. This is especially evident in the collaborative branch cache scheme. This changes the names of the filters to reflect the revs that _are_ included: hidden -> visible unserved -> served mutable -> immutable impactable -> base repoview.filteredrevs is renamed to filterrevs, so that callers read a bit more sensibly, e.g.: filterrevs('visible') # filter revs according to what's visible

clone: don't include empty revlogs in stream

serve: don't send any content headers with 304 responses Fixes HTTP protocol violation introduced in cf5c76017e11. 'hg serve' would show a stacktrace when loading pages that not had been modified. There was test coverage for this, but the wrong response headers wasn't shown and thus not detected.

tests: fix doctest stability over Python versions pprint ain't pretty in Python 2.4: Changed in version 2.5: Dictionaries are sorted by key before the display is computed; before 2.5, a dictionary was sorted only if its display required more than one line, although that wasn’t documented. Fixes issue introduced in 404feac78b8a.

tests: stabilize doctest output Avoid dependencies to dict iteration order.

tests: make test-hook.t output more stable

convert: make toposort order stable when multiple orderings are possible The output of some tests are changed. Not necessarily to the better, just other valid permutations.

convert: report cvsps branchpoints sorted

convert: process subversion branch in a sorted order

convert: process missing branches in sorted order

convert: process splicemap in sorted order

mq: stabilize update after strip of parent revision Strip will (if it updates) update to the parent of revs[0], where revs are the roots of the tree that is stripped. When revs was list(set) it was thus undefined which root parent it would update to. With sorted(set) it is at least stable what it updates to. (But it is very possible that another more useful and predictable behaviour could be defined ... such as updating to the tip-most surviving wd ancestor.)

histedit: process bookmarks in sorted order

churn: sort users with same churn by name This makes the output order well-defined and improves code readability.

largefiles: upload files in sorted order

hgweb: generate query strings with parameters sorted by key

identity: report bookmarks sorted

obsolete: process markers in a stable order Using set iteration order gave unstable debugsuccessorssets output with PYTHONHASHSEED=random.

subrepos: process subrepos in sorted order Add sorted() in places found by testing with PYTHONHASHSEED=random and code inspection. An alternative to sprinkling sorted() all over would be to change substate to a custom dict with sorted iterators...

bookmarks: process pulled remote bookmarks in sorted order

copies: report found copies sorted

discovery: process heads in sorted order

merge: process files in sorted order

commandserver: report capabilities sorted

bisect: store state sorted

localrepo: store branchheads sorted

localrepo: store requirements sorted

copies: make the loss in _backwardcopies more stable A couple of tests shows slightly more correct output. That is pure coincidence.

serve: use chunked encoding in hgweb responses 'hg serve' used to close connections when sending a response with unknown length ... such as a bundle or archive. Now chunked encoding will be used for responses with unknown length, and the connection do thus not have to be closed to indicate the end of the response. Chunked encoding is only used if the length is unknown, if the connection wouldn't be closed for other reasons, AND if it is a HTTP 1.1 request. This will not benefit other users of hgweb ... but it can serve as an example that it can be done.

serve: remove connection close hack for Python 2.3 Introduced in 276de216d2c5 and no longer needed - BaseHTTPServer handles connection closing just fine if we don't mess with its internals.

hgweb: pass the actual response body to request.response, not just the length This makes it less likely to send a response that doesn't match Content-Length.

hgweb: don't pass empty response chunks on hgweb internals will often produce empty writes - especially when returning compressed data. hgweb is no middleware application and there is thus no reason to pass them on to be processed in other layers.

hgweb: remove handling of any else than strings from request.write Iterators should be returned WSGI style, not written. And apparently all of hgweb do that.

serve: send response headers even if response has no body The headers would usually be sent anyway because the app did a number of writes of empty strings.

hgweb: simplify wsgirequest header handling Remove leaky header abstraction and prepare for other encodings.

hgweb: make type a mandatory parameter to request.respond There will thus always be headers and the runtime check can be removed.

hgweb: use Content-Length for pushres This prevents some unnecessary http connection close.

hgweb: send Content-Length 0 for zero length response Before, Content-Length wasn't sent for 0 length responses. Now it is. This could in principle prevent some unnecessary http connection close.

archival: tarit should never close the dest passed to it Some archive types closed the open file passed to it, some didn't. This could cause either missing or duplicate close and cause problems in hgweb. The fix in 14f3795a5ed7 should only have closed the compressors and archivers - not the underlying file itself if no compressor is used.

mq: checktoppatch should only check if p1 is qtip There is no way qtip in p2 could be used for anything, and there is thus no reason to check and accept it.

mq: fix qpop of working directory parent patch when not at qtip mq assumed that it had to update from qtip to qparent, and instead of updating from where it was it failed with: abort: working directory revision is not qtip

largefiles: make log match largefiles in the non-standin location too Yet another match hack.

log: make log work even if first parameter doesn't exist A slowpath optimization kicked in too often because of wrong indentation.

merge: remove "case" comments The comments introduced in f05c182430a0 seems important ... but the context has apparently been lost and they do not have any value now.

merge: merge file flags together with file content The 'x' flag and the 'l' flag are very different. It is usually not a problem to change the 'x' flag of a normal file independent of the content, but one does not simply change the type of a file to 'l' independent of the content. This removes the fmerge function that merged both 'x' and 'l' independent of content early in the merge process. This correctly introduces some conflicts instead of silent incorrect merges. 3-way flag merge will now be done in the resolve process, right next to file content merge. Conflicts can thus be resolved with (slightly inconvenient) resolve commands like 'resolve f --tool internal:other'. It thus brings us closer to be able to re-solve manifest merge after the merge and avoid prompts during merge. This also removes the "conflicting flags for a - (n)one, e(x)ec or sym(l)ink?" prompt that nobody could answer and that made it easy to mix symlink targets and file contents up. Instead it will give a file merge where a sufficiently clever merge tool can help resolving the issue.

tests: better test coverage of merges of flags This makes existing problems with merges of symlinks and files more obvious and add test coverage for tricky merges without real common ancestors.

merge: remove old pre-audit code checking for absolute paths Audit will handle this in a more elegant way.

merge: drop reference to file contents immediately after write Like 7d2aaeea67ed this reduces memory usage on large merges.

merge: changing the mode of a file is also an update It was a change in the file system that wasn't reported in the summaries.

merge: use util.unlinkpath for removing moved files - more like how removed files are removed.

merge: .hgsubstate is special as merge destination, not as merge source

merge: remove redundant unlink after merge The early prescan for move/remove and removal of moved files in applyupdates was introduced with mergestate 368a4ec603cc and rendered this chunk of code irrelevant. The impact of the chunk was reduced in 5b3383ea67d2 - but it could have been removed completely.

merge: rename list of actions from action to actions

merge: consistently use "x" instead of 'x' for internal action types This makes it simpler to search for places where the action types are handled.

merge: consistently use repo.wopener.audit instead of creating a new auditor

scmutil: simplify vfs.audit - drop wrapped vfs.auditor

util: copyfile: remove dest before copying This prevents spurious problems writing to locked files on Windows.

merge: warn when internal:merge cannot merge symlinks A follow-up to d084df89d948. internal:merge should never be picked for merging symlinks ... but in the test suite we have HGMERGE="internal:merge" which bypasses all the usual merge-tool cleverness. Without any output it can be hard to figure out what happened and where the problem is.

merge with stable

histedit: correct the number of added revisions in online help In the context of help document on which this patch focuses, the example repository, which is source of cloning, should be already histedit-ed, and contain only 3 revisions (rev # 0 to 2). So, not 3, but 4 revisions should be added to the destination repository of cloning, if it contains 7 revisions (rev # 0 to 6). This patch also adds modifier "histedit-ed" to "example repository", to make context clear.

histedit: correct changeset IDs in online help There is no '633536316234' revision in the example repository. It should be 'c561b4e977df', according to the revisions in it and explanation in help document.

convert: correct 'hooks' section name in online help The section name for hooks is not 'hook', but 'hooks'.

hgweb: document the revnavgen function

hgweb: no do not use listinsert(0, ...) This is not efficient. We now append element and either reverse the list or iterate in reverse order.

localrepo: drop unnecessary check on wlock unlock Calling out to dirstate one line before guarantees that it'll be in the filecache.

dirstate: refresh _branch cache entry after writing it

filecache: create an entry in _filecache when __set__ is called for a missing one Preserve the invariant that if P is a filecached property on X then P in X.__dict__ => P in X._filecache. Previously, it was possible for a filecached property to become out of sync with the filesystem if it was set before getting it first, since the initial filecacheentry was created in __get__. Old behaviour: repo.prop = x repo.invalidate() # prop has no entry in _filecache, it's not removed # from __dict__ repo.prop # returns x like before without checking with the # filesystem New: repo.prop = x # an empty entry is created in _filecache repo.invalidate() # prop is removed from __dict__ repo.prop # recreates prop

filecache: allow filecacheentry to be created without stating in __init__ Will be used for properties that are set without getting them first.

rollback: don't clear the filecache This was an old workaround to force the filecache to reload everything. Now that the syncing issue is fixed, we no longer need it.

destroyed: keep the filecache in sync with __dict__ (issue3335) (issue3693) (issue3743) We need to make sure that if X is in the filecache then it's also in the filecache owner's __dict__, otherwise it will go out of sync: repo.X # first access to X, records stat info in # filecache and updates __dict__ repo._filecache.clear() # removes X from _filecache but it's still in __dict__ repo.invalidate() # iterates over _filecache and removes entries # from __dict__, but X isn't in _filecache, so # it's kept in __dict__ repo.X # X is fetched from __dict__, bypassing the filecache

localrepo: write the phasecache when destroying nodes

localrepo: update the branchmap when destroying nodes This was previously called directly during strip. Moving it to destroying also means that it'll be called through _rollback, which seems harmless.

localrepo: introduce destroying function

localrepo: don't refresh filecache entries that aren't in __dict__ We call invalidate to remove properties from __dict__ because they're possibly outdated and we'd like to check for a new version. Next time the property is accessed the filecache mechanism checks the current stat info with the one recorded at the last time the property was read, if they're different it recreates the property. Previously we refreshed the stat info on all properties in the filecache when the lock is released, including properties that are missing from __dict__. This is a problem because: l = repo.lock() repo.P # stat info S for P is recorded in _filecache <changes are made to repo.P indirectly, e.g. underlying file is replaced> # P's new stat info = S' l.release() # filecache refreshes, records S' as P's stat info At this point our filecache contains P with stat info S', but P's version is from S, which is outdated. The above happens during _rollback and strip. Currently we're wiping the filecache and forcing everything to reload from scratch which works but isn't the right solution.

changelog: please check-code and remove tabs Tabs were introduced in 06185554e7e3.

branchmap: Save changectx creation during update The newly introduced `branchmap` function allows us to skip the creation of changectx objects. This speeds up the construction of the branchmap. On the mozilla repository (117293 changesets, 15490 mutable) Before: ! impactable 19.9 ! mutable 0.576 ! unserved 3.16 After: ! impactable 7.03 (2.8x faster) ! mutable 0.352 (1.6x) ! unserved 1.15 (2.7x) On the cpython repository (81418 changesets, 6418 mutable) Before: ! impactable 15.9 ! mutable 0.451 ! unserved 0.861 After: ! impactable 6.55 (2.4x faster) ! mutable 0.170 (2.6x faster) ! unserved 0.289 (2.9x faster) On the pypy repository (58852 changesets) Before: ! impactable 13.6 After: ! impactable 6.17 (2.2x faster) On my Mercurial repository (18295 changesets, 2210 mutable) Before: ! impactable 23.9 ! mutable 0.368 ! unserved 0.057 After: ! impactable 1.31 (18x faster) ! mutable 0.042 (8.7x) ! unserved 0.025 (2.2x)

changelog: add a `branch` method, bypassing changectx The only way to access the branch of a changeset is currently to create a changectx object and access its `branch()` method. Creating a new Python object is costly and has a huge impact on code doing heavy access to `branch()` (like branchmap). This change introduces a new method on changelog that allows direct access to the branch of a revision. See the next changeset for impact.

branchmap: pass revision insteads of changectx to the update function Creation of changectx objects is very slow, and they are not very useful. We are going to drop them. The first step is to change the function argument type.

perf: add perfbranchmap command The command times the update of a branchmap from its nearest subset or from scratch.

clfilter: enforce hidden filtering on all repository accesses We ensure all repositores created through `mercurial.hg.repository` are "hidden" filtered. This is an even stronger enforcement than 5bb610f87d1d. Citing Matt's response to changeset 5bb610f87d1d installing filtering in dispatch: > Unfortunately, this means that code that doesn't go through dispatch (ie all > those crazy misguided people using Mercurial as a library) are going to see > these hidden changesets. > > Might be better to instead install the filter in localrepo construction by > default and disable it in dispatch.

archival: avoid touching deprecated gzip name attribute The existing workaround didn't work when no filename was specified. If running in a context with warnings enabled and subsecond mtime it gave a warning: DeprecationWarning: use the name attribute

archival: pass integer to struct.pack int field instead of float If running in a context with warnings enabled and subsecond mtime it gave a warning: DeprecationWarning: integer argument expected, got float

largefiles: fix update from a merge with removed files A situation with this case could happen after interrupting an update. Update would fail with: abort: No such file or directory: $TESTTMP/f/.hglf/sub2/large6 Update from a merge without using clean is not possible anyway, so this patch takes a step in the right direction so it gets as far as reporting the right error.

largefiles: fix revert removing a largefile from a merge Before revert could fail with: abort: .hglf/large@33fdd332ec64: not found in manifest! The LookupError will now be caught and handled correctly.

largefiles: remove unused proto.refuseclient code Should have been removed with other pre-1.9 code in 7c604d8c7e83.

subrepo: make 'in subrepo' string easier to find by external tools This patch is meant to make it easier for tools that wrap the mercurial output (such as TortoiseHg) to find the "in subrepo MYSUBREPO" string that (since 9e3910db4e78) is appended after subrepo error messages, particularly when the mercurial output is translated to a non-English language. The message remains the same but the '%s' that was used to prepend the original error message in front of the 'in subrepo' string has been moved out of the translatable string. As an example of the usefulness of making it easy to look for "in subrepo MYSUBREPO" strings, TortoiseHg looks for these strings in error messages in order to "linkify them" (i.e. convert "MYSUBREPO" into alink to the corresponding subrepo). The original string made it hard for a tool such as TortoiseHg to look for the translated string on mercurial's output because the translated string contained the error message itself. This meant that a regular expression was required to ignore the error message part. With this change TortoiseHg can just get the translated "(in subrepo %s)" string, substitute %s for the subrepo path (which it gets from the subrepo exception) and simply search for the resulting string (no regular expression needed, or at least a much simpler regular expression could be used). Additionaly, the existing string could lead a translator mistakenly assume that it was possible invert the order of the %s (error and subrepo path) fields, which would not work because the string interpolation was position based.

subrepo: fix python2.4 compatibility after 9aa6bee6e9f9 super(SubrepoAbort, self).__init__(*args, **kw) raises TypeError: super() argument 1 must be type, not classobj

test-keyword: improve grammar and spelling in branchcache note See: da9e544c69d6

Merge with stable.

repoview: extract hideable revision computation in a dedicated function This will help extensions to plug into the hidden mechanism.

largefiles: make update with backup files in .hglf slightly less broken Largefiles update would try to copy f to f.orig if there was a .hglf/f.orig . That is in many many ways very very wrong, but it also caused an abort if f didn't exist. Now it only tries to copy f if it exists.

tests: fix up test-highlight for breadcrumb changes

color: add template label function

templater: add no-op template function 'label'

posix: fix split() for the case where the path is at the root of the filesystem posixpath.split() strips '/' from the dirname *unless it is the root*. This patch reproduces this behavior in posix.split(). The old behavior causes a crash when creating a file at the root of the repo with localrepo.wfile() when the repo is at the root of the filesystem.

record: remove unused import

cvsps: fix indentation

hghave: introduce a test (unused) for cvs >= 1.12

discovery: drop the visibleheads function It has no users left. (Using filtering explicitly is easier.)

clfilter: remove the last usage of `visibleheads` We can just inline the filtering now that all server code uses changelog filtering directly.

discovery: drop the visiblebranchmap function

clfilter: drop extra filtering in wireprotocol The repository used by wireprotocol is already filtered. We no longer need to call special functions.

clfilter: filter "unserved" on all wireprotocol command calls This ensures that unserved changesets are not exposed through the wire protocol.

clfilter: drop extra filtering in localpeer The repository used by localpeer is already filtered. We no longer need to call a special function.

clfilter: make localpeer use a repo with "unserved" filter This changeset installs a broad filter on most repos used for serving. This removes the need to use the `visiblehead`/`visiblebranchmap` functions, and ensures that changesets we should not serve are in fact never served. We do not use filtering on hgweb yet, as there is still a number of issues to solve there.

performance: speedup computation of extinct revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. This change drops revset calls in favor of direct testing of the phase of changesets. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! extinct ! wall 0.015124 After: ! extinct ! wall 0.009424 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! extinct ! wall 0.032844 After: ! extinct ! wall 0.000066

performance: speedup computation of suspended revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. This change drops a revset call in favor of direct testing of the phase of changesets. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! suspended ! wall 0.014319 After: ! suspended ! wall 0.009559 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! suspended ! wall 0.033373 After: ! suspended ! wall 0.000053

performance: speedup computation of unstable revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. This change drops revset call in favor of direct testing of the phase of changesets. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! unstable ! wall 0.017366 After this changes: ! unstable ! wall 0.008093 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! unstable ! wall 0.045190 After: ! unstable ! wall 0.000032

performance: speedup computation of mutable revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. The "mutable" filter is used during branch cache loading operation. We need to make it fast. This change drops revset calls in favor of direct testing of the phase of a changeset. Performance test on my Mercurial checkout - 19857 total changesets, - 1646 mutable revision Before: ! mutable ! wall 0.032405 After: ! mutable ! wall 0.001469 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 mutable changeset, Before: ! mutable ! wall 0.188636 After: ! mutable ! wall 0.000022

performance: speedup computation of unserved revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. The "unserved" filter is used in multiple applications, and in particular in some branch cache loading operations. We need to make it fast. This change drops revset calls in favor of direct testing of the phase of a changeset. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! unserved ! wall 0.030477 After: ! unserved ! wall 0.011844 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! unserved ! wall 0.111259 After: ! unserved ! wall 0.000084

performance: speedup computation of hidden revisions In their current state, revset calls can be very costlys, as we test predicates on the entire repository. The hidden filter is very widely used, and needs to be very fast. This change drops revset calls in favor of direct revision manipulation. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! hidden ! wall 0.077553 After this changes: ! hidden ! wall 0.011230 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! hidden ! wall 0.389472 After: ! hidden ! wall 0.000079

performance: speedup computation of obsolete revisions In their current state, revset calls can be very costly as we test predicates on the entire repository. As obsolete computation is used by the "hidden" filter, it needs to be very fast. This changet drops the revset call in favor of direct testing of the phase of a changeset. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! obsolete ! wall 0.047041 After: ! obsolete ! wall 0.004590 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! obsolete ! wall 0.001539 After: ! obsolete ! wall 0.000017

clfilter: drop unnecessary explicit filtering on histedit Hidden changeset filtering is now done at repo level. The orphaned children computation will not include any (unless you add --hidden).

clfilter: drop unnecessary explicit filtering on rebase Hidden changeset filtering is now done at repo level. The rebaseset computation will not include any (unless you add --hidden).

clfilter: ensure that hidden filtering is working on all commands Now that hidden changeset are filtered for all commands, we test the behavior of `heads` and `summary` regarding hidden changeset.

clfilter: enforce hidden changeset globally The dispatch code now enables filtering of "hidden" changesets globally. The filter is installed before command and extension invocation. The `--hidden` switch is now global and disables this filtering for any command. Code in log dedicated to changeset exclusion is removed as this global filtering has the same effect.

record: use patch.diffopts to account for user diffopts This allows user defined diff options (e.g. showfunc) to be accounted for when using record. A test has been updated accordingly.

convert: fix most test-check-code-hg violations in cvsps code

tests: update hgweb tests to include breadcrumbs

subrepo: add subrepo property to SubrepoAbort exceptions This new property contains the path of the subrepo that generated the exception. This information can then be used by GUI tools such as TortoiseHg.

tests: update test-convert-cvs*.t The preceding commit caused their outputs to change.

cvsps: use commitids (when present) to detect changesets Simplify core logic by no longer attempting to work around missing class attributes. Instead always generate the attributes and ignore the cache if the attributes are missing

hgweb, spartan: link from manifest title to changeset page

hgweb, spartan: add "URL breadcrumbs" This change adds a "URL breadcrumb" to the "title" of the pages on the spartan template. By title I mean the first line that is shown right below the page selection row, which shows the name of the page that is being viewed, along with some additional information. In doing so it standarizes those "titles" which now follow the pattern: URL breadcumb / page details

hgweb: add a "URL breadcrumb" to the index and repository pages The purpose of this change is to make it much easier to navigate up the repository tree when the hg web server is used to serve more than one repository. A "URL breadcrumb" is a path where each of the path items can be clicked to go to the corresponding path page. This lets you go up the folder hierarchy very quickly. For example, when showing the list of repositories in http://myserver/myteams/myprojects, the following "breadcrumb" will be shown: Mercurial > myteams > myprojects Clicking on "myprojects" reloads the page. Clicking on "myteams" goes up one folder. Clicking on the leftmost "Mercurial" goes to the server root. This "breadcrumb" also appears on all repository pages. For example on the summary page of the repository at http://myserver/myteams/myprojects/myrepo the following will be shown: Mercurial > myteams > myprojects > myrepo / summary This change has been applied to all templates that already had a link to the main repository page (i.e. gitweb, monoblue, paper and coal) plus to the index page of the spartan template. In order to make the breadcumb links stand out the some of the template styles have been customized.

merge: never do premerge on symlinks Simplemerge is not symlink aware and will never do the right thing on symlinks.

merge: make internal merge fail cleanly on symlinks Simplemerge is not symlink aware and will never do the the right thing on symlinks. It would read the symlink as a file and abort with 'No such file or directory' on dangling symlinks. Instead, internal:merge now simply fails to merge symlinks.

debugpushkey: list keys sorted

debugdiscovery: report heads in sorted order

hidden: drop of the repo.hiddenrevs property It does not have any user left

context: retrieve hidden from filteredrevs This prepare the dropping of the repo.hiddenrevs property

revset: retrieve hidden from filteredrevs This prepare the dropping of the `repo.hiddenrevs` property

hidden: use both parents of working directory If we are merging with and extinct revision, this extinct revision should not be hidden.

hidden: drop cache on hiddenrevs property The `filteredrevs` function already have a cache mechanism. And this cache in invalidated at the same time than the current property cache. So we drop the cache on the property. The property itself is going to be dropped soon.

hidden: move computation in filter function There is not good reason for this computation to be handle in a different way from the other. We are moving the computation of hidden revs in the filter function. In later changesets, code that access to `repo.hiddenrevs` will be updated and the property dropped.

branchcache: add note about cache invalidation to test-keyword.t [Should've been included in aff706b3a21c.] --Kevin Bullock <kbullock@ringworld.org>

clfilter: add impactable filter The `mutable` filter still have some chance to get invalidated. This will happen when: - you garbage collect hidden changeset, - public phase is moved backward, - something is changed in the filtering (this could be fixed) So we introduce an even more stable filtering set: everything with a revision number egal or higher than the first mutable changeset is filtered. The only official use of this filter is for branchcache.

clfilter: add mutable filtering It filters all mutable changesets, leaving only public changeset unfiltered. This filtering set is expected to be much more stable that the previous one as public changeset are unlikely to disapear. The only official use of this filter is for branchcache.

run-tests.py: fix handling of symlink to the right python Before: a symlink for python in BINDIR was sometimes created, but it was never updated when a different Python was used and it was never removed. An invalid python could thus be left around and used when testing with --local. Now: the symlink is removed when wrong and created when necessary. The mechanism for finding the right name (python or python.exe) also had to be simplified and made more explicit.

log: use "hidden" filtering instead of manual check at display time When log is not given the --hidden option, hidden revision are not shown. We move the implementation from manual checking at display time to changelog filtering. This is the first official usage of the hidden filtering.

clfilter: introduces a hidden filter This filter exclude all hidden revision. We plan to use this filter to hide revision instead of manually checking contents of the hidden revisions set.

perftest: allow selection of volatile set to benchmark This helps when you focus on a subset of the volatile chain.

perftest: add a command to benchmark construction of volatile cache Obsolescence and filtering related caches are critical. Having a handy way to check them is valuable.

perftest: add an option to invalidate volatile cache Some revsets are sensitive to such initialization. Being able to test the impact is great.

perftest: document the perfrevset command I'll add an argument to it.

perftest: migrate to new style command declaration Declaring synopsis and argument on the function site is much clearer.

perftest: drop duplicated codes The `perfnodelookup` lookup commands is duplicated. We drop the first version, overwritten by the seconds.

cmdutil: make options argument optional There is not reason to force passing of an empty options list.

branchmap: allow to use cache of subset Filtered repository are *subset* of unfiltered repository. This means that a filtered branchmap could be use to compute the unfiltered version. And filtered version happen to be subset of each other: - "all() - unserved()" is a subset of "all() - hidden()" - "all() - hidden()" is a subset of "all()" This means that branchmap with "unfiltered" filter can be used as a base for "hidden" branchmap that itself could be used as a base for unfiltered branchmap. unserved < hidden < None This changeset implements this mechanism. If the on disk branchcache is not valid we use the branchcache of the nearest subset as base instead of computing it from scratch. Such fallback can be cascaded multiple time is necessary. Note that both "hidden" and "unserved" set are a bit volatile. We will add more stable filtering in next changesets. This changeset enables collaboration between no filtering and "unserved" filtering. Fixing performance regression introduced by 47f00b0de337

repoview: add a subset table This will be used by branchmap collaboration. See inline documentation for more details

branchmap: add a copy method If we want branchcache of different filter to collaborate, they need a simple way to copy each other. This will ensure that each filtered have no side effect on other filter level cache.

clfilter: use empty frozenset intead of empty tuple This will allows set operation needed for cache collaboration.

run-tests.py: don't use console for stdin when running in debug mode Tests would wait for input instead of using non-interactive mode.

tests: make hghave and run-tests exit on unknown feature requirements

test-largefiles.t: fix wrong '#if hgweb' - it should be '#if serve' A bug introduced in 0c1d10351869 did that a part of the test never was run.

dispatch: show empty filename in OSError aborts Mercurial would sometimes exit with: abort: No such file or directory where str of the actual OSError exception was the more helpful: [Errno 2] No such file or directory: '' The exception will now always show the filename and quote it: abort: No such file or directory: ''

test-dispatch.t: remove incorrect "cd $dir" A line that should have been removed in 50fbe9063ff2.

merge with crew-stable

dispatch: handle empty `testedwith` value in extension When extensions had an empty `testedwith` attribute the code tried to parse it and failed. As a result the actual error were shallowed by a This crash. We now treat empty strip as 'unknown'

destroyed: filter unknown before computing branchcache Branchcache of filtered version need up to date phase data.

branchmap: disable fallback to unfiltered branchcache Disables this simple optimisation to allow coming more powerfull approach: cache collaboration. Our goal is to have branchcache collaborate. This means that unfiltered branchcache will fallback to some filtered branchcache if invalid. We can't have the filtered branchcache to use the unfiltered one. That would loop.

localrepo: filter unknown nodes from the phasecache on destroyed When commit is followed by strip (qrefresh), phasecache contains nodes that were removed from the changelog. Since phasecache is filecached with .hg/store/phaseroots which doesn't change as a result of stripping, we have to filter it manually. If we don't write it immediately, the next time it is read from disk the nodes will be filtered again. That's what happened before, but there's no reason not to write it immediately. The change in test-keyword.t is caused by the above.

phases: make _filterunknown a member function of phasecache We'd like the ability to call filterunknown on an existing phasecache instance after nodes are destroyed.

localrepo: drop `_cacheabletip` method It iss dead code now.

branchmap: drop `_cacheabletip` usage in `updatecache` Nobody overwrite the `_cacheabletip` any more. We always update the cache for the whole repo and write it to disk (or at list try to). The `updatecache` code is simplied to remove the double phase logic associated with _cacheabletip.

mq: drop `_cacheabletip` usage Strip have dedicated work around to solve the same problem, strip is even a fraction faster without that thanks to simpler update process of the branchcache.

bundlerepo: drop use of `_cacheabletip` Now that bundlerepo use a read only VFS, we do not worry about what part of the branchmap is written back to disk. Nothing is written at all.

bundlerepo: enforce reading from core repo only We do not want anything computed with the bundle overlay to be written back in the repo. Such write will likely contains invalid data. The short terms goal of this change is to drop use of `_cacheabletip` in bundle repo.