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.

branchmap: ignore Abort error while writing cache Read only vfs can now raise Abort exception. Note that encoding.local are also a possible raiser.

vfs: add a read only vfs This read only wrapper is intended to be used bundle repo. See follow up commit for details.

branchmap: read return None in case of failure This makes a clear distinction between having read a valid cache on disk or not. This will help caches of various filtering level to collaborate.

clfilter: fallback to unfiltered version when linkrev point to filtered history On `filectx`, linkrev may point to any revision in the repository. When the repository is filtered this may lead to `filectx` trying to build `changectx` for filtered revision. In such case we fallback to creating `changectx` on the unfiltered version of the reposition. This fallback should not be an issue because `changectx` from `filectx` are not used in complex operation that care about filtering. It is complicated to work around the issue in a clearer way as code raising such `filectx` rarely have access to the repository directly. Linkrevs create a lot of issue with filtering. It is stored in revlog entry at creation time and never changed. Nothing prevent the changeset revision pointed to become filtered. Several bogus behavior emerge from such situation. Those bugs are complex to solve and not part of the current effort to install filtering. This changeset is simple hack that prevent plain crash in favor on minor misbehavior without visible effect. This "hack" is longly documented in to code itself to help people that would look at it in the future.

phases: prepare phase command for filtering The phase command have some logic to report change made. We ensure this logic run unfiltered. With --force the command can change phase of a changeset for public to draft. Such change can lead to obsolescence marker to apply again and the changeset to be "hidden". If we do not run the logic unfiltered it could failed to fetch the phase of a newly filtered changeset.

phases: avoid changectx creation while checking command result This minor changesets saves the creation of a `changectx` ctx object only used to fetch the revision number.

test: use obsolescence marker to test hidden Instead of using a custom dedicated extension.

test-command-template.t: make "age" filter test work on Feb 29th reported by Julien Cristau.

merge with stable

Added signature for changeset a4765077b65e

Added tag 2.4.2 for changeset a4765077b65e

merge with i18n

merge i18n heads

hgweb, paper: add (Atom) subscribe links to the repository index This is similar to the subscribe links that already exist in other templates. Rather than the usual RSS and Atom links a single feed icon linking to the atom-log is shown.

hgweb: add (Atom) subscribe link to the main paper template pages The subscribe link is found at the bottom of the navigation sidebar. This uses a free icon from http://feedicons.com.

test-command-template.t: fix test so it all year This test started failing for me after midnight UTC on December 31st. Fixed it by specifying a date 7 years in the future more precisely (rather than just adding 8 to the year and specifying January 1st), which allows the test to pass both now and on 2012-12-01 at the same time.

amend: prevent loss of bookmark on failed amend The active bookmark were moved to the temporary commit. When the transaction were rollbacked, the bookmark were lost. We now temporarly disable the bookmark to prevent this effect.

amend: invalidate dirstate in case of failure (issue3670) The temporary commit created by amend update the dirstate. If the final commit fails, we need to invalidate the change made to the dirstate, otherwise the release of the wlock will write the dirstate created after the rollbacked temporary commit. This dirstate writing logic should probably be handled in the same object than the transaction one. However such change are too big for stable.

i18n-ru: delete loose letter

i18n-ru: synchonized with 777084ac8416

paper: sanity-check page feed links filelog has feeds in header, but not in menu bar help has header feeds pointing to tags

zeroconf: use port from server instead of picking port from config (issue3746) In order to get the port, wrap create server instead of hgweb_mod/hgwebdir_mod.

scmutil: don't try to match modes on filesystems without modes (issue3740)

hgwebdir: honor web.templates and web.static for static files (issue3734)

zeroconf: use port from server instead of picking port from config (issue3746) In order to get the port, wrap create server instead of hgweb_mod/hgwebdir_mod.

branchmap: enable caching for filtered version too The `_branchcache` attribute is turned into a dictionary. Key are filter name and value is a `branchcache` object. Unfiltered version is cached as `None` filter. The attribute is renamed to `_branchcaches` to avoid confusion with the previous one. Both old and new contents are dictionary even if their contents are different. I prefer possible extension code to crash right away instead of just messing the wrong dictionary. As all different caches work isolated to each other, this code keeps the previous behavior of using the unfiltered cache we nothing is filtered. This is a cheap way to have cache collaborate and nullify potential impact in the default case.

branchmap: report filtername when read fails Now that we can have multiple one, we need to know which filecache failed to be read from disk.

branchmap: use a different file name for filtered view of repo

clfilter: ensure unfiltered repo have a filtername attribute too That will allows to use `repo.filtername` for dispatch purpose.

branchmap: move the cache file name into a dedicated function Filtered view of the repo will want to write they file name in a different file.

branchmap: read and write key part related to filtered revision Now that we have a third part for the cache key we need to write and read it on disk. It is only written when there is filtered revision. This keep the format compatible with older version. Notes that, at this state, filtered repository does not use any disk caches yet.

check-code: disallow defunct <> operator Added a test for that and one other python3 check in test-check-code.t.

largefiles: stop using <> operator in favor of != <> has been deprecated for a while, and != is futureproof

commands: fix implicit tuple that is invalid syntax in Python3

check-code: disallow two-argument form of raise Using this old form makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

httpclient: apply change df9aea1def3e: remove use of two-argument raise

test-symlink-os-yes-fs-no.py: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

scmutil: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

url: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

win32: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

commandserver: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

test-command-template.t: fix test so it all year This test started failing for me after midnight UTC on December 31st. Fixed it by specifying a date 7 years in the future more precisely (rather than just adding 8 to the year and specifying January 1st), which allows the test to pass both now and on 2012-12-01 at the same time.

cmdutil: make getgraphlogrevs limit-aware For a repository with over 400,000 changesets, this speeds up graphlog with a small limit by around 0.05 seconds (~50%).

cmdutil: stop pretending we can calculate revs for graphlog lazily cmdutil.getgraphlogrevs does a ton of work trying to build a graphlog lazily, and then cmdutil.graphlog comes along and destroys all of that. graphmod.dagwalker requires that it be given the full list of revs upfront so that it can perform filtering and tests against known revs. For a repository with over 400,000 changesets, this speeds up graphlog by around 0.02 seconds (~20% with a small limit).

cmdutil: store a local ref to repo.hiddenrevs in getgraphlogrevs On a repository with over 400,000 changesets, this speeds graphlog up by around 0.03 seconds (~20% with a small limit).

cmdutil: make getgraphlogrevs return revs in descending order

branchmap: takes filtered revision in account for cache calculation Tracking tipnode and tiprev is not enough to ensure validaty of the cache as they do not help distinguish a cache that ignored various revisions below tiprev. To detect such difference, we build a hash of all ignored revisions. This hash is then used when checking the validity of a cache for a repo.

branchmap: improve computation of target tip With revision filtering the effective revision number of "tip" may be lower than: len(changelog) - 1 We now use a more correct version preventing useless writing on disk in some case.

branchmap: improve invalid cache message when reading This factors out the generation of the message. This helps future error reporting when reading cache for filtered repository.

histedit: allow operation from non-head if obsolete is enabled Obsolescence markers can represent this situation just fine. Rewritten revisions are marked as precursors of the ones creates by histedit. Unaffected descendants become "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.

rebase: allow non-head rebase-set when obsolete is enabled Obsolescence markers can represent this situation just fine. Rebased revisions are marked as precursors of the ones create by rebase. Unrebased descendants becomes "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.

amend: allow amend of non-head when obsolete is enabled Obsolescence marker can represent this situation just fine. The old version is marked as precursor of the new changeset. All its descendants become "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.

obsolete: factorise troubles detection during push The use of the two methods introduced earlier allows a factorisation of the push code preventing push of troubled changeset.

obsolete: introduce a troubles method on context A troubled changeset may be affected by multiple trouble at the same time. This new method returns a list of all troubles affecting a changes.

obsolete: introduce a troubled method on context Allows to quickly check if a changeset is affected by any troubles. (troubles are: unstable, bumped and divergent)

tests: fix windows test failures

merge with stable

tests: fix windows test failures

largefiles: better test coverage of wireproto and the http protocol

largefiles: cleanup of warnings on errors getting largefiles Especially the "no default or default-push path set in hgrc" was often very misleading and didn't give any hint where it actually was looking. A long error messages is better than several multi-line messages.

largefiles: remove trivial portability wrappers

largefiles: remove reporemove portability wrapper

largefiles: remove findoutgoing portability wrapper

largefiles: use constant for '.hglf/' Problem: '.hglf' + '/' was computed in some tight loops. There is no need for that.

largefiles: use plain wjoin instead of the complex pathto

largefiles: unindent code

largefiles: simplify lfdirstate ignore handling - it is only for tracking .hglf

largefiles: rename 'admin' to more descriptive 'lfstoredir'

largefiles: simplify lfutil.getstandinmatcher by inlining getmatcher

largefiles: remove overly complex handling of ignored and unknown files

largefiles: introduce basic debugstate --large functionality Very useful for debugging largefiles "performance" issues. This is used for testing 03faf12fbee7.

util: fold ENOENT check into unlinkpath, controlled by new ignoremissing flag Refactor a common pattern.

merge with stable

largefiles: don't walk through all ignored files Problem: 'hg status' with largefiles enabled would walk through all the files that .hgignore said should be ignored. That made it slow if a lot of files were .hgignored or the cache was cold. It seems like there was a reason to this, but other improvements has rendered this unnecessary. Solution: .hgignore is now only ignored when that is requested (--ignore). This is a minimal 'stable' change. There is room for other improvement.

largefiles revert: update lfdirstate with result from first cleanliness check Largefiles revert do for some reason have two lfdirstates and lfdirstatestatus invocations in one function. The result from the first lfdirstate check was however not written back to the lfdirstate, and some files was thus checked twice.

largefiles status: update lfdirstate with result from cleanliness check Problem: 'hg status' kept checking largefiles with an unknown state until some other command wrote the updated dirstate. Solution: Add missing lfdirstate.write().

bundlerepo: don't return the peer without bundlerepo from getremotechanges Problem: getremotechanges would return the 'other' repo if nothing was incoming and there thus wasn't any bundle to base the repo on. The 'other' could be a http peer which only implement the functionality available over the http protocol. Transplant could thus fail with TypeError: argument of type 'httppeer' is not iterable Solution: Return the local repo instead of the remote peer if there is no reason to place a bundlerepo on top of the local repo.

strip: do not update branchcache during strip (issue3745) At this moment, the cache is invalid, and will be thrown away. Later the strip function will call the `localrepo.destroyed` method that will update the branchmap cache.

copies: do not track backward copies, only renames (issue3739) The inverse of a rename is a rename, but the inverse of a copy is not a copy. Presenting it as such -- in particular, stuffing it into the same dict as real copies -- causes bugs because other code starts believing the inverse copies are real. The only test whose output changes is test-mv-cp-st-diff.t. When a backwards status -C command is run where a copy is involved, the inverse copy (which was hitherto presented as a real copy) is no longer displayed. Keeping track of inverse copies is useful in some situations -- composability of diffs, for example, since adding "a" followed by an inverse copy "b" to "a" is equivalent to a rename "b" to "a". However, representing them would require a more complex data structure than the same dict in which real copies are also stored.

copies: make debug messages more sensible The -> in debug messages is currently overloaded to mean both source to dest and dest to source. To fix this, we add explicit labels and make the arrow direction consistent.

copies: separate moves via directory renames from explicit copies Currently the "copy" dict contains both explicit copies/moves made by a context and pending moves that need to happen because the other context moved the directory the file was in. For explicit copies, the dict stores a destination to source map, while for pending moves via directory renames, it stores a source to destination map. The merge code uses this fact in a non- obvious way to differentiate between these two cases. We make this explicit by storing these pending moves in a separate dict. The dict still has a source to destination map, but that is called out in the docstring.

merge with stable

branchmap: move validity logic in the object itself In several place, We check if a branchcache is still valid regarding the current state of the repository. This changeset puts this logic in a method of the object that can be reused when necessary. A branch map is considered valid whenever it is up to date or a strict subset of the repository state. The change will help making branchcache aware of filtered revision. The change in keyword is expected. the branch cache is actually invalid after the amend. The previous check did not detected it.

branchmap: make update a method

branchmap: make update responsible to update the cache key The update function have all necessary data to keep the branchcache key up to date with its value. This saves assignment to the cache key that each caller of update had to do by hand. The strip case is a bit more complicated to handles from inside the function but I do not expect any impact.

branchmap: factorise changelog access in update This both improves readability and performance. Access to changelog of filtered repository currently have a minor overhead.

branchmap: make write a method on the branchmap object

branchmap: simplify write signature All necessary data (cache value and key) are now stored in the branchcache object. Any extra parameter is superfluous.

branchmap: add the tiprev (cache key) on the branchmap object The actual cache key used on disk is the (tipnode, tiprev) pair. There is no reason not to use the revision number for the in memory version.

branchmap: add the tipnode (cache key) on the branchcache object Gathering data and cache key paves the way to a lot of simplification.

branchmap: store branchcache in a dedicated object Value and key of branchcache would benefit from being hold by the same object. Moreover some logic (update, write, validation) could be move on such object. The creation of this object is the first step toward this move. The result will clarify branchcache related code and hide most of the detail in the class itself. This encapsulation will greatly helps implementation of branchcache for filtered view of the repo.

branchmap: `stream_in` write remote branchcache to local one The previous code was writing it to a non existent `branchcache` attribute. We now write is to the proper `_branchcache` attribute and initialize the `_branchcachetip` at the same time. We keep writing it to disk, the previous code had this part right.

bookmarks: fix head selection for merge with two bookmarked heads A type mismatch caused the search for the other head to fail. The code is fragile, and instead it ended up using the 'first' bookmark head, but the ordering is undefined and it could thus randomly use the wrong bookmarkhead and fail with: $ hg up -q -C e@diverged $ hg merge abort: merging with a working directory ancestor has no effect

branchmap: extract updatebranchcache from repo

branchmap: extract _updatebranchcache from repo

branchmap: _updatebranchmap does not need to be filtered The `_updatebranchmap` method on repo does not need to be filtered as all callers are already handling filtering themself. The fact it is filtered may had even lead to buggy behaviors, but by chances the method make very sparse use of the repo object.

branchmap: extract read logic from repo

branchmap: extract write logic from localrepo

branchmap: create a mercurial.branchmap module This is the foundation stone for an extraction of branches map logic from local repository class. Most of the branches map logic have very few caller and therefor does not fit in the current criteria for code held by the localrepo class. Important change will be made to this code in relation with revision filtering. So we extract it in a dedicated module before adding additional complexity. Follow up commit do the actual code movement.

bundlerepo: use _cacheabletip mechanism in bundlerepo Instead of preventing any cache write we allow writing cache for all content of the original repo. The motivation for this change is to drop the custom _writebranchcache of bundlerepo to help extraction of the branchmap logic out of localrepo.

branchmap: merge _branchtags into updatebranchcache Now that nobody overwrite it, there is no reasons for `_branchtags` to remains separated from `updatebranchcache`.

branchmap: factorise access to changelog in updatebranchcache This prepares merge of `updatebranchcache` and `_branchtags`.

branchmap: simplify _branchtags using a new _cacheabletip method The current _branchtags method is a remnant of an older, much larger function. Its only remaining role is to help MQ to alter the version of branchcache we store on disk. As MQ mutates the repository it ensures persistent cache does not contain anything it is likely to alter. This changeset makes explicit the stable vs volatile part of repository and reduces the MQ specific code to the computation of this limit. The main _branchtags code now handles this possible limit in all cases. This will help to extract the branchmap logic from the repository. The new code of _branchtags is a bit duplicated, but as I expect major refactoring of this section I'm not keen to setup factorisation function here.

hook: disable demandimport before importing hooks This solved an obscure bug for me. In upgrading Distribute on the server, a patch was added to has a try: import a except ImportError thing that's only supposed to work with Python 3.3. I'm using 2.7. My hook failed with an ImportError because of this. It seems kind of sensible to turn off demandimport before importing the hook, since the except ImportError pattern is used quite a bit in Python code (including in other Distribute code).

test-pathencode: accept --seed parameter in hex as well test-pathencode.py outputs the seed value in hex if it finds a deviation. This change allows to specify the seed value as a command line parameter for test-pathencode.py in hex as well.

subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.

tests: fix some slash-based Windows failures

inotify: on Python < 2.6, socket.error lacks errno

hidden: invalidate hiddenrevs when needed The `hiddenrevs` cache is volatile too (It use content from `obscache`). When unsure it is invalidated when necessary. In a near future, the cache will probably be moved to `revsfiltercache`

cache: group obscache and revsfiltercache invalidation in a single function Both caches are very volatile and needs invalidation on the same kind of event. revsfiltercache actually depends on the content of revsfiltercache.

clfilter: use filtering in `visibleheads` This is the second real use of changelog filtering. The change is very small to allow testing the new filter with a setup close to the original one. We replace custom post processing on `heads`function by call to the standard code pass on a filtering repo. In later coming will have wider usage of filtering that will make the dedicated function useless.

clfilter: use filtering in `visiblebranchmap` Here is the first real use of changelog filtering. The change is very small to allow testing the new filter with a setup close to the original one. We replace custom post processing on branchmap function by call to the standard code pass on a filtering repo. In later coming will have wider usage of filtering that will make the dedicated function useless.

clfilter: introduce a "unserver" filtering mode This mode is for repository used as a server. It filter secret and hidden changeset out. It is put to use in later changeset.

clfilter: add a cache on repo for set of revision to filter for a given set. Recomputing the filtered revisions at every access to changelog is far too expensive. This changeset introduce a cache for this information. This cache is hold by the repository (unfiltered repository) and invalidated when necessary. This cache is not a protected attribute (leading _) because some logic that invalidate it is not held by the local repo itself.

clfilter: add actual repo filtering mechanism We add a `filtered` method on repo. This method return an instance of `repoview` that behaves exactly as the original repository but with a filtered changelog attribute. Filters are identified by a "name". Planned filter are `unserved`, `hidden` and `mutable`. Filtering the repository in place what out of question as it wont not allows multiple thread to share the same repo. It would makes control of the filtering scope harder too. See the `repoview` docstring for details. A mechanism to compute filtered revision is also installed. Some caches will be installed in later commit.

inotify: pacify pestiferous pyflakes precipitously

tests: make test-inotify-issue1208.t disappear

posix: move server side of unix domain sockets out of inotify We also turn the unix domain socket into a class, so that we have a sensible place to hang its logically related attributes and behaviour. We'll shortly want to reuse this in other code.

inotify: don't fall over just because of a dangling symlink Previously, the inotify server failed to start if .hg/inotify.sock was a symlink that pointed to a non-existent path. This behaviour does not seem to make any sense. Now, if we encounter a broken symlink, we unlink it and continue.

test-inotify: test symlink indirection for unix sockets The inotify code performs a delicate dance to work around the 108-byte limit on unix domain socket path names on Linux. This change sets us up to safely refactor that code without breaking it. (It is redundant with part of test-inotify-issue1208.t, but we will shortly make that test go away.)

test-pathencode: compare current pathencoding implementations We already have two implementations of the pathencoding (C and Python) and this test can perfectly well be used to probabilistically test them instead of just wasting CPU cycles and test time.

rebase: use lazy ancestor membership testing For a repository with over 400,000 commits, rebasing one revision near tip, this avoids one walk up the DAG, speeding the operation up by around 0.8 seconds.

localrepo: use lazy ancestor membership testing For a repository with over 400,000 commits, rebasing one revision near tip, this avoids two treks up the DAG, speeding the operation up by around 1.6 seconds.

ancestor: add lazy membership testing to lazyancestors This also makes the perfancestorset command use lazy membership testing. In a linear repository with over 400,000 commits, without this patch, hg perfancestorset takes 0.80 seconds no matter how far behind we're looking. With this patch, hg perfancestorset -- X takes: Rev X Time -1 0.00s -4000 0.01s -20000 0.04s -80000 0.17s -200000 0.43s -300000 0.69s 0 0.88s Thus, for revisions close to tip, we're up to several orders of magnitude faster. At 0 we're around 10% slower.

revlog: move ancestor generation out to a new class This refactoring is to prepare for implementing lazy membership.

ignore: process hgignore files in deterministic order Previously, we processed them in whatever order the dict iterator gave us.

ignore: only read an ignore file once

ignore: refactor ignore into two functions This prepares us for eventually being able to hash the list of patterns in use.

clfilter: fix `nodemap` usage in `getbundle` With the current implementation, `changelog.nodemap` is not filtered. So some filtered changeset in common are not filtered by `n in nodemap`. This leads to crash lower in the stack when the bundle generation try to access those node on a filtered changelog.

test: fix truncated comment in test The push is made to ensure repository are related. The comment in the initial changeset got truncated somehow.

clfilter: ensure context raise RepoLookupError when the revision is filtered Currently the code path of `changectx(filteredrepo, rev)` call `filteredrepo.changelog.node(rev)`. When `rev` is filtered this raise an unhandled `IndexError`. This case now raise a `RepoLookupError` as other error case do.

revlog: remove incancestors since it is no longer used

transplant: replace incancestors uses with ancestors

revlog.ancestors: add support for including revs This is in preparation for an upcoming refactoring. This also fixes a bug in incancestors, where if an element of revs was an ancestor of another it would be generated twice.

perf: add command to test performance of membership in ancestor set The new command, perfancestorset, takes an argument denoting which revset to test the membership of. Currently this runs through all the ancestors and converts them into a set. The primary purpose of having this is to compare this approach, currently used in several places, against the upcoming lazy approach.

ancestor: move missingancestors doctest out into a separate file This is in preparation for upcoming patches which will reuse the same graph for tests.

merge with crew-stable

dirstate: remove obsolete comment from setbranch This comment should have been removed in b74361cf7c0a, when the call to scmutil.checknewlabel was removed.

dirstate: don't rename branch file if writing it failed

commands: 'hg bookmark NAME' should work even with ui.strict=True Before this patch, enabling strict command processing (ui.strict=True) meant that 'hg bookmark NAME', as referenced several places in the documentation, would not work. This adds 'bookmark' as an explicit alias to 'bookmarks'.

tests: improve test-mv-cp-st-diff.t readability

obsolete: refuse to push divergent changeset As other troubles `unstable` and `bumped`. Followup patches may simplify the push code with unification of "obsolescence troubles" handling.

obsolete: add a divergent method on context The same we have `unstable` and `bumped`. Convenient method to access troubles information in general may land later. This get actual use and testing in the next changesets.

obsolete: add revset and test for divergent changesets This changesets add a new `divergent()` revset similar to `unstable()` and `bumped()` one. Introducting this revset allows actuall test of the divergent detection.

obsolete: detect divergent changesets Divergent changeset are final successors (non obsolete) of a changeset who compete with another set of final successors for this same changeset. For example if you have two obsolescence markers A -> B and A -> C, B and C are both "divergent" because they compete to be the one true successors of A. Public revision can't be divergent. This function is used and tested in the next changeset.

obsolete: drop successors sets which are subset of another one If both "(B,)" and "(B, C)" are successors set of "A", "(B,)" is dropped. We won't be interrested in detection such divergence scenario.

obsolete: compute successors set Successors set are an important part of obsolescence. It is necessary to detect and solve divergence situation. This changeset add a core function to compute them, a debug command to audit them and solid test on the concept. Check function docstring for details about the concept.

mq: don't fail when removing a patch without patch file from series file

largefiles: align rm warnings with warnings used in core

merge with stable

largefiles: commit directories that only contain largefiles (issue3548) If we pass a directory to commit whose only commitable files are largefiles, the core commit code aborts before finding the largefiles. So we do the following: For directories that only have largefiles as matches, we explicitly add the largefiles to the matchlist and remove the directory. In other cases, we leave the match list unmodified.

revset.children: ignore rev numbers that are too low This replaces unnecessary parentrevs() calls with calculating min(parentset). Even though the min operation is O(size of parentset), since parentrevs is relatively expensive, this tradeoff almost always works in our favour. In a repository with over 400,000 changesets, hg perfrevset "children(X)" takes: Set X Before After -1 0.51s 0.06s -1000: 0.55s 0.08s -10000: 0.56s 0.10s -100000: 0.60s 0.25s -100000:-99000 0.55s 0.19s 0:100000 0.60s 0.61s all() 0.72s 0.74s The relative performance is similar for Mercurial's own repository -- several times faster in most cases, slightly slower for revisions close to 0 and all().

perf: add a command to measure revset performance

run-tests: fix whitespace nonsense

merge with mpm

run-tests: on windows, put correct python at front of PATH The older approach of trying to copy the python executable into the test directory was doomed to fail. There remains one weakness with this approach: if you've run "make local", tests may pick up the wrong extension DLLs from inside the source tree. I don't know why this happens. A reasonable workaround for now is to test either using --local or with a working directory that does not contain built DLLs.

run-tests: fix exename on Windows

run-tests: support running tests in parallel on windows Previously, we used os.spawnvp, which doesn't exist on Windows, and isn't needed anyway (the command line begins with an absolute path). We also need a slightly more convoluted way to wait for processes without specifying an order on Windows, as it lacks os.wait.

makefile: allow local builds to work on windows/mingw32

check-code: make 'missing whitespace in assignment' more aggressive New warnings: > a.b=ab missing whitespace in assignment (the pattern did not accept '.' on the left hand side) > a=a missing whitespace in assignment (the right hand side pattern never matched a single character) > a=a + 7 missing whitespace in assignment (the pattern only matched one character after the identifier following =)

check-code: there must also be whitespace between ')' and operator The check pattern only checked for whitespace between keyword and operator. Now it also warns: > x = f(),7 missing whitespace after , > x = f()+7 missing whitespace in expression

rm: drop misleading 'use -f' hint for the rm --after 'not removing' warning A warning mentioning 'forgetting' or 'recording delete' would be more correct than 'not removing' but also more confusing.

contrib: state explicitly how hgtest.vim can be installed

tests: kill daemons early, making breaking at "Accept" prompt safe

run-tests: use correct python safely under --jobs

run-tests: check for the correct python when starting

run-tests: use correct python when run with --local

synthrepo: do not crash if a list is empty

hgwebdir: do not show RSS and Atom links for plain directories Up until now the templates that show RSS and Atom feeds on the "repository lists" (i.e. gitweb and monoblue) showed them for all entries, including regular folders. Clicking on those "folder RSS" links would result in an error page being shown. This patch hides those links for regular folders.

hgweb: add branches RSS and Atom feeds There were no RSS nor Atom feeds for the branches page. Different hgweb templates linked to different feeds on their branches page (some linked to the tags feed, some to the log feed and some to the unexisting branches feed).

push: reunite comment with the line of code it describes

bookmarks: spelling correction in docstring

merge: fix mistake in moved _checkcollision call from 5881d5b7552f

windows: correctly pass a mode to S_IFMT in statfiles

strip: make query to get new bookmark target cheaper The current query to get the new bookmark target for stripped revisions involves multiple walks up the DAG, and is really expensive, taking over 2.5 seconds on a repository with over 400,000 changesets even if just one changeset is being stripped. A slightly simplified version of the current query is max(heads(::<tostrip> - <tostrip>)) We make two observations here. 1. For any set s, max(heads(s)) == max(s). That is because revision numbers define a topological order, so that the element with the highest revision number in s will not have any children in s. 2. For any set s, max(::s - s) == max(parents(s) - s). In other words, the ancestor of s with the highest revision number not in s is a parent of one of the revs in s. Why? Because if it were an ancestor but not a parent of s, it would have a descendant that would be a parent of s. This descendant would have a higher revision number, leading to a contradiction. Combining these two observations, we rewrite the revset query as max(parents(<tostrip>) - <tostrip>) The time complexity is now linear in the number of changesets being stripped. For the above repository, the query now takes 0.1 seconds when one changeset is stripped. This speeds up operations that use repair.strip, like the rebase and strip commands.

graft: explicit current node tracking This changes graft to explicitly track the progression of commits it makes, and updates it's idea of the current node based on it's last commit, rather than from the working copy parent. This should have no effect on the value of current since we were reading the working copy parent immediately after commiting to it. The motivation for this change is that a subsequent patch will break the current node and working copy relationship. Splitting this out into a separate patch will make that one more readible.

graft: move commit info building This moves the logic for generating the commit metadata ahead of the merge operation. The only purposae of this patch is to make subsequent patches easier to read, and there should be no behavior changes.

merge with stable

merge: support calculating merge actions against non-working contexts This is not currently used. It is instead a pre-requisite to performing non-conflicting grafts in memory, which a subsequent patch will do.

merge: refactor action calculation into function This pulls the code used to calculate the changes that need to happen during merge.update() into a separate function. This is not useful on its own, but is instead preparatory to performing grafts in memory when there are no potential conflicts.

dirstate: inline more properties and methods in status hg perfstatus -u on a working directory with 170,000 files, without this change: ! wall 1.839561 comb 1.830000 user 1.120000 sys 0.710000 (best of 6) With this change: ! wall 1.804222 comb 1.790000 user 1.140000 sys 0.650000 (best of 6) hg perfstatus on the same directory, without this change: ! wall 1.016609 comb 1.020000 user 0.670000 sys 0.350000 (best of 10) With this change: ! wall 0.985573 comb 0.980000 user 0.650000 sys 0.330000 (best of 10)

perf: add option to perfstatus to get the status of unknown files When status needs to look at unknown files (e.g. when running hg status), it needs to use a completely different algorithm than when it doesn't (e.g. when running hg diff).

dirstate: test normalize is truthy instead of using a no-op lambda hg perfstatus -u on a working directory with 170,000 files, without this change: ! wall 1.869404 comb 1.850000 user 1.170000 sys 0.680000 (best of 6) With this change: ! wall 1.839561 comb 1.830000 user 1.120000 sys 0.710000 (best of 6)

merge with stable

hgweb: avoid generator exhaustion with branches

hgweb: fix iterator reuse in atom feed generation

tests: don't hardcode errno==2 for ENOENT Hurd seems to set ENOENT to 2 + 2**30, unlike everyone else.

osutil: tab damage, how i hate thee

osutil: write a C implementation of statfiles for unix This makes a big difference to performance. In a clean working directory containing 170,000 files, performance of "hg --time diff" improves from 2.38 seconds to 1.69.

merge with i18n

i18n-ja: synchronized with f94ead934067

Added signature for changeset 0c10cf819146

Added tag 2.4.1 for changeset 0c10cf819146

osutil: fix tab damage

Merge with crew

osutil: factor out creation and init of listdir_stat

dirstate: avoid use of zip on big lists In a clean working directory containing 170,000 tracked files, this improves performance of "hg --time diff" from 1.69 seconds to 1.43. This idea is due to Siddharth Agarwal.

dirstate: move file type filtering to its source This prepares us to move to a much faster statfiles implementation on Unix.

clfilter: rename `unfilteredmeth` to `unfilteredmethod` As originally intended.

clfilter: fix a false positive in the test-obsolete.t We push between two repo which once filtered looks unrelated. Weakness in the current implementation allows this push to be done without -f. But later improvement with filtering will make this push fails for unrelatedness. However we want this push to fail for including bumped changeset. So we had a smaller push --force to make them related.

clfilter: ensure that filecache on localrepo is unfiltered All filecache usage on repo is for logic that should be unfiltered. The caches should be common to all filtered instances, and computation must be done unfiltered. A dedicated storecache subclass is created for this purpose.

clfilter: add a propertycache that must be unfiltered Some of the localrepo property caches must be computed unfiltered and stored globally. Some others must see the filtered version and store data relative to the current filtering. This changeset introduces two classes `unfilteredpropertycache` and `filteredpropertycache` for this purpose. A new function `hasunfilteredcache` is introduced for unambiguous checking for cached values on unfiltered repos. A few tweaks are made to the property cache class to allow overriding the way the computed value is stored on the object. Some logic relative to _tagcaches is cleaned up in the process.

largefile: status is buggy on repoproxy, so run unfiltered For some yet-unkown reason, largefile status does not work on repoproxy. As status is not affected by filtering, we run it unfiltered. Na'Tosha Bard's view on this issue: "but, well, largefiles status is kind of an unholy piece of code"

clfilter: mq should not warn about filtered mq patches MQ warns when qstatus contains unknown nodes. With changelog filtering, a node may be unknown because it is filtered. Thus, an unfiltered repo is used for this check.

clfilter: ensure that mq performs commits on unfiltered repos

clfilter: use unfiltered repo for bookmark push logic The remote location of the bookmark may be filtered locally. This changeset ensures that bookmark movement logic has access to all the repo's content.

clfilter: `bookmark.validdest` should run on unfiltered repo The logic recently added to `bookmark.validdest` uses data about obsolete changesets to see if a bookmark destination is valid. Obsolete changesets are likely to be filtered, so we need to work on an unfiltered repository.

clfilter: unfilter some parts of the push logic Computation of common changesets during push needs to be done on the widest set possible. An unfiltered version of the repo is kept for discovery and various revset calls. The discovery code itself enforces the filtering of unserved outgoing changeset.

subrepo: add argument to "diff()" to pass "ui" of caller side (issue3712) (API) Color extension achieves colorization by overriding the class of "ui" object just before command execution. Before this patch, "diff()" of abstractsubrepo and classes derived from it has no "ui" argument, so "diff()" of hgsubrepo uses "self._repo.ui" to invoke "cmdutil.diffordiffstat()". For separation of configuration between repositories, revision 573bec4ab7ba changed the initialization source of "self._repo.ui" from "ui"(overridden) to "baseui"(plain) of parent repository. And this caused break of colorization. This patch adds "ui" argument to "diff()" of abstractsubrepo and classes derived from it to pass "ui" object of caller side.

clfilter: prevent unwanted warning about filtered parents as unknown During changectx __init__ the dirstate's parents MAY be checked. If the repo is filtered, this check will complain "working directory has unknown parents" even if the parents are perfectly known. This may happen when the repo is used for serving and the dirstate has parents that are secret, as those secret changesets will be filtered.

clfilter: strip logic should be unfiltered Strip is a "write" operation that needs to be aware of the whole repo's content before destroying changesets. Only the low level function is altered. The top level command will still process its argument filtered (if any filtering is in place).

clfilter: verify logic should be unfiltered To verify a changelog obviously needs all of it. The verify logic now ensures it works on an unfiltered repository.

clfilter: phases logic should be unfiltered Phase computations and boundary movements need to be aware of all revisions that exist in the repository to return correct results.

clfilter: unfilter computation of obsolescence related computation All obsolescence related sets need to be computed on the full unfiltered version of the repository, in particular because several of them (obsolete, extinct) are used to compute the hidden revisions. On a filtered repo, revset predicates related to these sets will be properly filtered because of revset's own pre-filtering.

clfilter: ensure changeset creation in the repo is run unfiltered This applies to both creation of new commits and application of changegroups.

clfilter: ensure changegroup generation is run unfiltered Changegroup generation logic needs to be aware of the whole repository to work properly.

clfilter: ensure `rollback` is run unfiltered Rollback logic needs to be aware of the whole repository to work properly.

clfilter: ensure cache invalidation is done on the main unfiltered repo The proxy version will not hold any cache for now. But we have to ensure all cache operations are done on the unfiltered version.

clfilter: ensure that tag logic runs unfiltered The current tag logic is not aware of filtering. We keep the status quo, ensuring that the tag cache is computed as before: without any filtering.

clfilter: ensure `branchcache` logic runs unfiltered The current branchcache construction is not aware of filtering. We keep the status quo, ensuring that the branch cache logic is computed as before: without any filtering.

clfilter: introduce an `unfilteredmethod` decorator This decorator ensure the method in run on an unfiltered version of the repository. See follow-up commit for details. This decorator is not named `unfiltered` because it would clash with the `unfilteredmethod` on `localrepo` itself.

clfilter: introduce an "unfiltered" method on localrepo This commit is part of the changelog level filtering effort. It returns the main "unfiltered" version of a repo-like object. For localrepo this means the same localrepo object. But this method will be overwritten by the filtered versions of a repository to return the core unfiltered version of the repo. Introducing this simple method first allows later commits to prepare for the use of a filtered version of a repository. A new repo method is added because a lot of users may call it. At the end of this series of commits, about 40 calls exist in core and hgext.

clfilter: remove usage of `range` and `xrange` in scmutil.revrange For changelog level filtering to take effect it need to be used for any iteration. This changeset removes usage of `range` and `xrange` that survived the first pass.

hgweb: display diff for a changeset against any parents (issue2810) During merge of branches, it is useful to compare merge results against the two parents. This change adds this support to hgweb. To specify which parent to compare to, use rev/12300:12345 where 12300 is a parent changeset number. Two links are added to changeset web page so that one can choose which parent to compare to.

branch: add missing repo argument to checknewlabel scmutil.checknewlabel takes a repo object as its first argument. When the call to this function was added in e689b0d91546, the first argument was mistakenly set to 'None'.

Merge with stable.

rebase: fix pull --rev options clashing with --rebase (issue3619) Rebase also have a plain `--rev` option used to select the rebase set (as `--base` or `--source` would). But the content of the --rev option was intended for the remote repo and is irrelevant for the local rebase operation. We expect `hg pull --rebase` to stick with the default behavior here: hg rebase --base . --dest tip(branch(.)) The `rev` option is dropped from the option passed to rebase.

dirstate: remove obsolete comment from setbranch This comment should have been removed in e689b0d91546, when the call to scmutil.checknewlabel was removed.

merge with stable

tests: fix broken fix of test-phases output

update: allow update to existing branches with invalid names (issue3710) Starting with 361ab1e2086f, users are no longer able to update a working copy to a branch named with a "bad" character (such as ':'). Prior to v2.4, it was possible to create branch names using "bad" characters, so this breaks backwards compatibility. Mercurial must allow users to update to existing branches with bad names. However, it should continue to prevent the creation of new branches with bad names. A test was added to confirm that 'hg update' works as expected. The test uses a bundled repo that was created with an earlier version of Mercurial.

commit: increase perf by building a new addlist instead of editing the old one When commiting to a repo with lots of files (>170000), manifest.py:addlistdelta takes some time because it's editing a large array many times. Changing it to build a new array instead of editing the old one saves around 0.04 seconds on a 1.64 second commit. A 2.5% gain. The gain here is pretty minor, but it was blatantly at the top of the profiler report and the fix is straight forward. I tested it by comparing the arrays produced by the new and old logic while running all of the tests.

template engine: convert generator-based iterator to list-based iterator If a template iterator is implemented with generator, the iterator is exhau= sted after we use it. This leads to undesired behavior in template. This chang= e converts a generator-based iterator to list-based iterator when template en= gine first detects a generator-based iterator. All future usages of iterator wi= ll use list instead.

command: remove phase from the list of basic command This is not a basic command. There is no reason new user should needs to know about it. Thanks to Matt Mackall for pointing this.

merge with stable

phases: fix missing "error" module import (issue3707)

test-mq-qrefresh: test that the patch at qtip is indeed empty ...after qrefreshing a non-existent file

tests: only call check-code once The accepted warnings list is now empty, let's try to keep it that way.

ancestor: fix a comment (followup to 0b03454abae7)

revlog: allow reverse iteration with revlog.revs We often need to perform rev iteration in reverse order. This changeset makes it possible to do so, in order to avoid costly reverse or reversed() calls later.

convert: add config option to use the local time zone The default for the time zone offset in a converted changeset has always been 0 (UTC). With this patch, the converted changeset is modified so that the local offset from UTC is specified as the time zone offset. The option is specified as the boolean convert.localtimezone (default False). Example usage: hg convert -s cvs --config convert.localtimezone=True example-cvs example-hg IMPORTANT: the patch only applies to conversions from cvs or svn. The documentation for the option only appears in those two sections in the convert help text.

rebase: use revlog.findmissingrevs to compute detach set

revlog: add rev-specific variant of findmissing This will be used by rebase in an upcoming commit.

revlog: switch findmissing to use ancestor.missingancestors This also speeds up other commands that use findmissing, like incoming and merge --preview. With a large linear repository (>400000 commits) and with one incoming changeset, incoming is sped up from around 4-4.5 seconds to under 3.

ancestor: faster algorithm for difference of ancestor sets One of the major reasons rebase is slow in large repositories is the computation of the detach set: the set of ancestors of the changesets to rebase not in the destination parent. This is currently done via a revset that does two walks all the way to the root of the DAG. Instead of doing that, to find ancestors of a set <revs> not in another set <common> we walk up the tree in reverse revision number order, maintaining sets of nodes visited from <revs>, <common> or both. For the common case where the sets are close both topologically and in revision number (relative to repository size), this has been found to speed up rebase by around 15-20%. When the nodes are farther apart and the DAG is highly branching, it is harder to say which would win. Here's how long computing the detach set takes in a linear repository with over 400000 changesets, rebasing near tip: Rebasing across 4 changesets Revset method: 2.2s New algorithm: 0.00015s Rebasing across 250 changesets Revset method: 2.2s New algorithm: 0.00069s Rebasing across 10000 changesets Revset method: 2.4s New algorithm: 0.019s

bisect: add example for limiting bisection to specified directories The bisect command does not have an option to limit itself only to subdirectories, but it's possible to use revsets for the --skip option for the same effect. Given the relative obscurity of revsets, it helps to have this as another example for bisect.

subrepo: use posixpath when diffing, for consistent paths This fixes a Windows failure in test-subrepo-recursion.t introduced by c84ef0047a94.

run-tests: fix an unnoticed check-code violation

run-tests: add a --compiler option Without this option, it is not possible to run the test suite on Windows using mingw's gcc as the compiler.

run-tests: make build command line less intimidating Use a dict for parameters to the format string, instead of a ridiculous number of positional parameters.

hooks: be even more forgiven of non-fd descriptors (issue3711) Looks like there are instances where sys.stdout/stderr contain file handles that are invalid. We should be tolerant of this for hook I/O redirection, as our primary concern is not garbling our own output stream.

hooks: delay I/O redirection until we actually run a hook (issue3711) We were attempting to redirect I/O even if no hook was actually getting called. This defers redirection until we've found something to do.

util: make chunkbuffer non-quadratic on Windows The old str-based += collector performed very nicely on Linux, but turns out to be quadratically expensive on Windows, causing chunkbuffer to dominate in profiles. This list-based version has been measured to significantly improve performance with large chunks on Windows, with negligible overall overhead on Linux (though microbenchmarks show it to be about 50% slower). This may increase memory overhead where += didn't behave quadratically. If we want to gather up 1G of data to join, we temporarily have 1G in our list and 1G in our string.

revset: backed out changeset 54cedee86e51 This was causing clones of the hg repo to go from 12.4s to 14.7s.

hgk: specify some colours explicitly in hex Tk 8.6b3 uses web colours, where green is defined as #008000, not #00ff00, and grey is #c0c0c0, not #808080, so specify those colours explicitly.

hgk: no committer please Generate committer only if we really have it. Update test-hgk.t accordingly.

hgk: use Ttk instead of plain Tk Use Ttk (themed Tk) for most of the widgets. Default to xpnative theme on Windows, clam otherwise. Provide a shim for Tk 8.4 without Tile/Ttk.

check-code: move i18n check from warning to error

i18n: wrap false positives for translation detection

eol: don't refer to a random name-captured ui object Previously, we used a ui object captured at the time of monkeypatching.

mq: don't refer to a random name-captured repo object Previously, we used a repo object captured at the time of monkeypatching.

Merge with crew-stable

commit: increase perf by avoiding checks against entire repo subsets When commiting to a repo with lots of history (>400000 changesets) checking the results of revset.py:descendants against the subset takes some time. Since the subset equals the entire changelog, the check isn't necessary. Avoiding it in that case saves 0.1 seconds off of a 1.78 second commit. A 6% gain. We use the length of the subset to determine if it is the entire repo. There is precedence for this in revset.py:stringset.

commit: increase perf by avoiding unnecessary filteredrevs check When commiting to a repo with lots of history (>400000 changesets) the filteredrevs check (added with 5c89e7fa5bc2) in changelog.py takes a bit of time even if the filteredrevs set is empty. Skipping the check in that case shaves 0.36 seconds off a 2.14 second commit. A 17% gain.

merge with crew-stable

grep: remove useless while condition A revised version of 35ba170c0f82 was sent to the list that fixed this <http://markmail.org/message/jmfuiise5igcyh2m>, but the older version of the patch was applied.

merge with mpm

test-pathencode: more aggressively check for python < 2.6

diff: move index header generation to patch In an upcoming patch, we will add index information to all git diffs, not only binary diffs, so this code needs to be moved to a more appropriate place. Also, since this information is used for patch headers, it makes more sense to be in the patch module, along with other patch-related metadata.

patch: make _addmodehdr a function under trydiff addmodehdr is a header helper, same as diffline, so it doesn't need to be a top-level function and can be nested under trydiff. In upcoming patches we will generalize this approach for all headers.

diff: rewrite diffline Make diffline more readable, using strings with placeholders rather than appending to a list from many ifs that makes difficult to understand the actual output format.

diff: swap and simplify diffline args Args order swapped, since a, b are more important than revs (which is only used on non-git format), and change to read opts from context.

diff: change how quiet mode supresses diffline Before, quiet mode produced no diffline header for mercurial as a side effect of not populating "revs". This was a weird side effect, and we will always need revs for git index header that will be added in upcoming patches, so now we just check ui.quiet from diffline directly.

diff: move diffline to patch module diffline is not part of diff computation, so it makes more sense to place it with other header generation in patch module. In upcoming patches we will generalize this approach for all headers added in the patch, including the git index header.

diff: unify calls to diffline diffline was called from trydiff for binary diffs and from unidiff for text diffs. In this patch we unify those calls into one. diffline is also a header, not part of diff mechanisms, so it makes sense to remove that responsibility from the mdiff module. In upcoming patches we will move diffline to patch module and keep grouping responsibilities.

diff: move b85diff to mdiff module b85diff generates a binary diff, so we move this code to mdiff module along with unidiff for text diffs. All diffing mechanisms will be in the same place. In an upcoming patch we will remove the responsibility to print the index header from b85diff and move it back to patch, since it's a patch metadata header, not part of the diff generation.

share: always set default path to work with subrepos (issue3518) set the default path in any case because creating subrepo looks this up. Subrepos are cloned, not shared.

vfs: optimize __call__ by not calling util.split for reads dirname and basename are not used on reads

run-tests: backout 4a4173519b63 This deleted work in progress to eliminate child processes for -j.

test-pathencode: make a 2.4-safe import of collections