store: rename "openertype" argument to "vfstype"

localrepo: use "vfs" constructor instead of "opener" one This patch also changes initialization order of "*opener" and "*vfs" fields: first, "*vfs" fields are initialized , and then, "*opener" ones are initialized.

scmutil: rename classes from "opener" to "vfs" For backwards compatibility, aliases for the old names are added, except for "abstractopener", "statichttpopener" and "_fncacheopener", because these are not used in Mercurial core implementation after this patch. "_fncacheopener" was only referred in "fncachestore" constructor, so this patch also renames from "_fncacheopener" to "_fncachevfs" there.

doc: add the tool to check section marks in help documents This patch adds "doc/check-seclevel.py" which checks below in help documents: - whether unknown or unavailable section marks are used or not - whether appropriate section mark is used at sub-sectioning It should be invoked in "doc" directory. It checks all help documents of Mercurial (topics, commands, extensions), if no file is specified by --file option. With --file option, it checks contents of the specified file as help document, for self testing purpose: -t/-c/-e/-C are used to specify what kind of help document contents of the specified file is. This checking is related to changeset 979b107eaea2.

histedit: replaces patching logic by merges The old and fragile patching logic is replaced by smart merges (as rebase and graft do). This should prevents some conflicts and smoother human resolution. For this purpose the "foldchanges" function is renamed to "applychanges" and handle a single revision only.

histedit-test: ensure that non commute test will never commute The previous version would commute if using merge algorithm (to be accurate, merge will cleanly prompt the user during the merge). The new version create and initial commit with some content for all involved files en ensure all changes are a content changes of the first lines. This lead to guaranteed conflict when commuted.

histedit: display action being processed in debug mode This is very useful when debugging histedit.

histedit: fold in memory Update the folding code to works in memory instead of applying patches on the working directory. This is cleaner, faster and prepare the removal of the whole patching logic. This new collapse function will probably move into core sooner or later. A lot of other rewriting operation may benefit from it.

histedit: move makedesc function near other rules related function Having it in the middle of action logic is confusing

histedit: move `between function` outside the action logic Having this function in the middle of action and patching logic did not make sense

histedit document the makedest function

histedit: documents the between function

templatefilters: add parameterized date method

templatefilters: add parameterized fill function

templater: pull in functions defined in templatefilters

templater: add if/ifeq conditionals

templater: add sub() function

templater: correctly deal with r"" strings

template: add join function This allows: {join(files % "{files}", ", ") }\n to produce a properly comma-separated list

templater: factor out runtemplate method As a side-effect, this makes the output of runmap non-flattened

templating: make new-style templating features work with command line lists

formatter: improve implementation of data method This alternate syntax was proposed by Bryan O'Sullivan in a review of 772b3764d3e8. I haven't been able to measure any particular performance difference, but the new syntax is more concise and easier to read.

Merge with crew-stable

archival: add "extended-timestamp" extra block for zip archives (issue3600) Before this patch, zip archives created by "hg archive" are extracted with unexpected timestamp, if TZ is not configured as GMT. This patch adds "extended-timestamp" extra block to zip archives, and unzip will extract such archives with timestamp specified in added extra block, even though TZ is not configured as GMT. Please see documents below for detail about specification of zip file format and "extended-timestamp" extra block: http://www.pkware.com/documents/casestudies/APPNOTE.TXT http://www.opensource.apple.com/source/zip/zip-6/unzip/unzip/proginfo/extra.fld Original implementation of this patch was suggested by "Jun Omae <jun66j5@gmail.com>".

bookmarks: use "changectx.descendant()" for efficient descendant examination This patch uses "old.descendant(new)" expression instead of "new in old.descendants()" for efficiency.

context: add "descendant()" to changectx for efficient descendant examination This patch adds "descendant()", which uses "revlog.descendant()" for descendant examination, to changectx. This implementation is more efficient than "new in old.descendants()" expression, because: - "changectx.descendants()" creates temporary "changectx" objects, but "revlog.descendant()" doesn't "revlog.descendant()" checks only revision numbers of descendants. - "revlog.descendant()" stops scanning, when scanning of all revisions less than one of examination target is finished this can avoid useless scanning in "not descendant" case.

bookmarks: avoid redundant creation/assignment of "validdests" in "validdest()"

store: add a fallback _pathencode Python function which does the equivalent of parsers.pathencode, so it can be used as a default

store: move _plainhybridencode and _dothybridencode higher up in the file no functional change

test-hybridencode: use store._dothybridencode(s) and compare it with the result of store._hybridencode(s, True)

store: fix _hashencode call in _dothybridencode Fixes 7840d81a80ec

check-code: catch yield inside try/finally (with tests) This is not allowed in Python 2.4.

Merge with mpm

store: use native fncache encoding function if available This currently falls back to Python for hashed encoding.

tests: run test-hybridencode.py over both Python and C encoders This ensures that the two always give the same answers.

store: implement fncache basic path encoding in C (This is not yet enabled; it will be turned on in a followup patch.) The path encoding performed by fncache is complex and (perhaps surprisingly) slow enough to negatively affect the overall performance of Mercurial. For a short path (< 120 bytes), the Python code can be reduced to a fairly tractable state machine that either determines that nothing needs to be done in a single pass, or performs the encoding in a second pass. For longer paths, we avoid the more complicated hashed encoding scheme for now, and fall back to Python. Raw performance: I measured in a repo containing 150,000 files in its tip manifest, with a median path name length of 57 bytes, and 95th percentile of 96 bytes. In this repo, the Python code takes 3.1 seconds to encode all path names, while the hybrid C-and-Python code (called from Python) takes 0.21 seconds, for a speedup of about 14. Across several other large repositories, I've measured the speedup from the C code at between 26x and 40x. For path names above 120 bytes where we must fall back to Python for hashed encoding, the speedup is about 1.7x. Thus absolute performance will depend strongly on the characteristics of a particular repository.

rebase: ensure rebase does not revive extinct revision Here, we exclude hidden changesets from a rebase operation. If we don't, a rewritten version of the hidden changesets will be created by rebase. Those rewritten versions won't be hidden and will likely conflict with other rewriting or revive pruned changeset. Moreover, rewriting hidden revisions will surprise the user. This change would not be necessary if changelog filtering were already in core. But it's fairly cheap and helps to increase the test-suite for such filtering. Once changelog level filtering is added, hidden changes will be automatically excluded or included according to the global --hidden flags. Plain ignoring them is good enough for now.

rebase: remove useless list around repo.revs As repo.revs already returns a list.

rebase: properly handle --collapse when creating obsolescence marker In collapse mode, that content of state is not suitable to compute obsolescence markers. We explicitly pass the resulting revision instead and use it as the successors for all elements of the rebased set.

rebase: allow creation obsolescence relation instead of stripping When obsolescence feature is enabled we now create markers from the rebased set to the resulting set instead of stripping. The "state" mapping built by rebase holds all necessary data. Changesets "deleted" by the rebase are marked "succeeded" by the changeset they would be rebased one. That the best guess of "successors" we have. Getting a successors as meaningful as possible is important for automatic resolution of obsolescence troubles. In other word, emptied changeset will looks collapsed with their former parents. (see "empty changeset" section of the test if you are still confused)

rebase: extract final changesets cleanup logic in a dedicated function At the end of the rebase, rebased changesets are currently stripped. This behavior will be eventually dropped in favor of obsolescence marker creation. The main rebase function is already big and branchy enough. This changeset move the clean-up logic in a dedicated function before we make it more complex.

store: refactor hashed encoding into its own function

store: reuse direncoded path in _hybridencode For a netbeans clone on Windows 7 x64: Before: $ hg perffncacheencode ! wall 3.516000 comb 3.525623 user 3.525623 sys 0.000000 (best of 3) After: $ hg perffncacheencode ! wall 3.443000 comb 3.447622 user 3.447622 sys 0.000000 (best of 3)

store: extract functions _encodefname and _decodefname

store: use fast C implementation of encodedir() if it's available For a netbeans clone on Windows 7 x64: Encoding all paths in the fncache: Before: $ hg perffncacheencode ! wall 3.639000 comb 3.634823 user 3.634823 sys 0.000000 (best of 3) After: $ hg perffncacheencode ! wall 3.470000 comb 3.463222 user 3.463222 sys 0.000000 (best of 3) Writing fncache: Before: $ hg perffncachewrite ! wall 0.103000 comb 0.093601 user 0.093601 sys 0.000000 (best of 95) After: $ hg perffncachewrite ! wall 0.081000 comb 0.078001 user 0.062400 sys 0.015600 (best of 100)

pathencode: new C module with fast encodedir() function Not yet used (will be enabled in a later patch). This patch is a stripped down version of patches originally created by Bryan O'Sullivan <bryano@fb.com>

store: add multiline doctest case for encodedir() a followup to 64c6a0d4d4bd

store: optimize fncache._load a bit by dirdecoding the contents in one go For a netbeans clone on Windows 7 x64: Before: $ hg perffncacheload ! wall 0.124000 comb 0.124801 user 0.124801 sys 0.000000 (best of 76) After: $ hg perffncacheload ! wall 0.096000 comb 0.093601 user 0.078001 sys 0.015600 (best of 97)

wireproto: workaround for yield inside try/finally incompatible with python2.4

merge with stable

largefiles: delegate to the wrapped clone command This allows the wrapped command's validation code to run (which is currently only to ensure 'noupdate' and 'updaterev' aren't both specified), the copy/pasted unpacking of hg.clone() args to be removed, and any future changes to the base command (however unlikely) to be inherited by largefiles. Unfortunately, the command override can't be swapped entirely for an hg.clone() override because the extra --all-largefiles arg needs to be injected. It also isn't enough to call the wrapped clone command and leave the caching code after it, because the file caching code needs access to the destination repo, which is only available from hg.clone(). An alternative would be to use the dest path in the clone command override to re-obtain a reference to the repo. A slight deviation from the regular hg.clone() function is that the repo is NOT deleted if the caching fails, but that was also the previous behavior. Maybe it should for consistency?

largefiles: don't convert dest=None to dest=hg.defaultdest() in clone command A status message is output if hg.clone() determines the default destination because None was provided. The previous code never passed None to hg.clone().

largefiles: restore caching of largefiles with 'clone -U --all-largefiles' This was broken when restoring normal -u and -U functionality.

largefiles: restore normal 'clone -u' and 'clone -U' functionality Previously, tip would be checked out regardless of the -u or -U parameter. I'm not sure what the 'required for successful walkchangerevs' comment meant, but it appears to reference code which has since moved to downloadlfiles() in 7d6a660ca151. Perhaps it was to force caching when the -U parameter is given? The price of this change is that -U --all-largefiles won't cache anything. That will be fixed next. Note that X + Y in the 'X largefiles updated, n removed' and 'Y additional largefiles cached' lines do not add up to the same values in these tests, but all of the largefiles have been downloaded. The reason being that several largefiles have the same content (eb7338044 is pointed to by sub/large2, large3 and sub/large4). In the 'clone -u 1' operation, this largefile is cached to populate the working directory, even without --all-largefiles. That means the file isn't downloaded again and cached in the rev where large3 and sub/large4 both point to this file. Downloading that one file in that one rev seems to be counted twice with 'clone -u 0'. (Maybe it is also being downloaded twice?)

formatter: add base implementation of data method Previously, nothing was done with the passed in values, which clearly wasn't the intention.

merge with stable

merge with main

largefiles: fix trailing spaces in test-largefiles.t With the default branch this will cause warnings from check-code.

test-hybridencode: add a case for direncode

store: optimize fncache._write by direncoding the contents in one go For a netbeans clone on Windows 7 x64: Before: $ hg perffncachewrite ! wall 0.210000 comb 0.218401 user 0.202801 sys 0.015600 (best of 47) After: $ hg perffncachewrite ! wall 0.104000 comb 0.109201 user 0.078000 sys 0.031200 (best of 95)