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

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

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

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

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

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

hg: replace DirCleanup class with normal try/finally use

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

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

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

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

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

store: switch to C-based hashed path encoding

pathencode: implement both basic and hashed encoding in C

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

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

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

store: implement lowerencode in C

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

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

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

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

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

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

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

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

zsh_completion: add descriptive branch names to head revisions

zsh_completion: add completion of branch names

zsh_completion: fix issue with overlong branch/tag names

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

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

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

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

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

bundlerepo: drop bundlebase wrapper function for basemap

bundlerepo: remove unused disktiprev attribute

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

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

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

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

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

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

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

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

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

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

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

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

tests: more comment cleanup related to obsolescence

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

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

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

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

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

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

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

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

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

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

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

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

refactoring: use unlinkpath with ignoremissing

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

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