Mon, 30 Mar 2015 17:21:49 -0700 treemanifest: add treemanifest._isempty()
Drew Gottlieb <drgott@google.com> [Mon, 30 Mar 2015 17:21:49 -0700] rev 24551
treemanifest: add treemanifest._isempty() During operations that involve building up a new manifest tree, it will be useful to be able to quickly check if a submanifest is empty, and if so, to avoid including it in the final tree. Doing this check lets us avoid creating treemanifest structures that contain any empty submanifests.
Fri, 27 Mar 2015 13:16:13 -0700 treemanifest: remove treemanifest._intersectfiles()
Drew Gottlieb <drgott@google.com> [Fri, 27 Mar 2015 13:16:13 -0700] rev 24550
treemanifest: remove treemanifest._intersectfiles() In preparation for the optimization in the following commit, this commit removes treemanifest.matches()'s call to _intersectfiles(), and removes _intersectfiles() itself since it's unused at this point.
Mon, 30 Mar 2015 11:58:39 -0700 manifest: add some tests for manifest.matches()
Drew Gottlieb <drgott@google.com> [Mon, 30 Mar 2015 11:58:39 -0700] rev 24549
manifest: add some tests for manifest.matches() There were no tests for the various code paths in manifestdict.matches(), so I added some. This also adds a more complex testing manifest so that any bugs relating to traversal of directories are more likely to be caught.
Tue, 31 Mar 2015 17:42:46 -0400 forget: cleanup the output for an inexact case match on icasefs stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 31 Mar 2015 17:42:46 -0400] rev 24548
forget: cleanup the output for an inexact case match on icasefs Previously, specifying a file name but not matching the dirstate case yielded the following, even though the file was actually removed: $ hg forget capsdir1/capsdir/abc.txt not removing capsdir\a.txt: file is already untracked removing CapsDir\A.txt [1] This change doesn't appear to cause any extra filesystem accesses, even if a nonexistant file is specified. If a directory is specified without a case match, it is (and was previously) still silently ignored.
Mon, 30 Mar 2015 21:37:24 -0700 json: implement {branches} template
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Mar 2015 21:37:24 -0700] rev 24547
json: implement {branches} template
Tue, 31 Mar 2015 14:54:56 -0700 json: implement {bookmarks} template
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 31 Mar 2015 14:54:56 -0700] rev 24546
json: implement {bookmarks} template
Tue, 31 Mar 2015 14:52:21 -0700 json: implement {tags} template
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 31 Mar 2015 14:52:21 -0700] rev 24545
json: implement {tags} template Tags is pretty easy to implement. Let's start there. The output is slightly different from `hg tags -Tjson`. For reference, the CLI has the following output: [ { "node": "e2049974f9a23176c2addb61d8f5b86e0d620490", "rev": 29880, "tag": "tip", "type": "" }, ... ] Our output has the format: { "node": "0aeb19ea57a6d223bacddda3871cb78f24b06510", "tags": [ { "node": "e2049974f9a23176c2addb61d8f5b86e0d620490", "tag": "tag1", "date": [1427775457.0, 25200] }, ... ] } "rev" is omitted because it isn't a reliable identifier. We shouldn't be exposing them in web APIs and giving the impression it remotely resembles a stable identifier. Perhaps we could one day hide this behind a config option (it might be useful to expose when running servers locally). The "type" of the tag isn't defined because this information isn't yet exposed to the hgweb templater (it could be in a follow-up) and because it is questionable whether different types should be exposed at all. (Should the web interface really be exposing "local" tags?) We use an object for the outer type instead of Array for a few reasons. First, it is extensible. If we ever need to throw more global properties into the output, we can do that without breaking backwards compatibility (property additions should be backwards compatible). Second, uniformity in web APIs is nice. Having everything return objects seems much saner than a mix of array and object. Third, there are security issues with arrays in older browsers. The JSON web services world almost never uses arrays as the main type for this reason. Another possibly controversial part about this patch is how dates are defined. While JSON has a Date type, it is based on the JavaScript Date type, which is widely considered a pile of garbage. It is a non-starter for this reason. Many of Mercurial's built-in date filters drop seconds resolution. So that's a non-starter as well, since we want the API to be lossless where possible. rfc3339date, rfc822date, isodatesec, and date are all lossless. However, they each require the client to perform string parsing on top of JSON decoding. While date parsing libraries are pretty ubiquitous, some languages don't have them out of the box. However, pretty much every programming language can deal with UNIX timestamps (which are just integers or floats). So, we choose to use Mercurial's internal date representation, which in JSON is modeled as float seconds since UNIX epoch and an integer timezone offset from UTC (keep in mind JavaScript/JSON models all "Numbers" as double prevision floating point numbers, so there isn't a difference between ints and floats in JSON).
Mon, 30 Mar 2015 20:15:03 -0700 templates: add a stub template for json
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Mar 2015 20:15:03 -0700] rev 24544
templates: add a stub template for json Many have long wanted hgweb to emit a common machine readable output. We start the process by defining a stub json template. Right now, each endpoint returns a stub "not yet implemented" string. Individual templates will be implemented in subsequent patches. Basic tests for templates have been included. Coverage isn't perfect, but it is better than nothing.
Mon, 30 Mar 2015 20:56:54 -0700 get-with-headers: support parsing and pretty printing JSON
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 Mar 2015 20:56:54 -0700] rev 24543
get-with-headers: support parsing and pretty printing JSON Upcoming patches will add support for JSON output from hgweb. Because JSON output from the templater is hard to read and because it is easy to introduce malformed JSON, we introduce a JSON processing mode to get-with-headers.py that will parse and pretty print JSON from HTTP responses. This will make tests easier to read and write and it will ensure hgweb is emitting well-formed JSON.
Tue, 31 Mar 2015 16:14:14 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 31 Mar 2015 16:14:14 -0500] rev 24542
merge with stable
Sun, 29 Mar 2015 19:47:16 -0700 dirstate.walk: use the file foldmap to normalize
Siddharth Agarwal <sid0@fb.com> [Sun, 29 Mar 2015 19:47:16 -0700] rev 24541
dirstate.walk: use the file foldmap to normalize Computing the set of directories in the dirstate is expensive. It turns out that it isn't necessary for operations like 'hg status' at all. Why? Consider the file 'foo/bar' on disk, which is represented in the dirstate as 'FOO/BAR'. On 'hg status', we'd walk down the directory tree, coming across 'foo' first. Before: we'd normalize 'foo' to 'FOO', then add 'FOO' to our visited stack. We'd then visit 'FOO', finding the file 'bar'. We'd normalize 'FOO/bar' to 'FOO/BAR', then add it to the results dict. After: we wouldn't normalize 'foo' at all. We'd add it to our visited stack, then visit 'foo', finding the file 'bar'. We'd normalize 'foo/bar' to 'FOO/BAR', then add it to the results dict. So whether we normalize intermediate directories or not actually makes no difference in most cases. The only case where normalization matters at all is if a file is replaced with a directory with the same case-folded name. In that case we can do a relatively cheap file normalization instead and still get away with not computing the set of directories. This is a nice boost in status performance. On OS X with case-insensitive HFS+, for a large repo with over 200,000 files, this brings down 'hg status' from 4.00 seconds to 3.62.
Sun, 29 Mar 2015 19:42:49 -0700 dirstate: split the foldmap into separate ones for files and directories
Siddharth Agarwal <sid0@fb.com> [Sun, 29 Mar 2015 19:42:49 -0700] rev 24540
dirstate: split the foldmap into separate ones for files and directories Computing the set of directories in the dirstate can be pretty expensive. For 'hg status' without arguments, it turns out we actually never need to figure out the right case for directories in the foldmap. (An upcoming patch explains why.) This patch splits up the directory and file maps into separate ones, allowing for the subsequent optimization in status.
Sat, 28 Mar 2015 18:53:54 -0700 dirstate: introduce function to normalize just filenames
Siddharth Agarwal <sid0@fb.com> [Sat, 28 Mar 2015 18:53:54 -0700] rev 24539
dirstate: introduce function to normalize just filenames This will be used in upcoming patches to stop generating the set of directories in many common cases.
Sun, 29 Mar 2015 19:23:05 -0700 dirstate: factor out code to discover normalized path
Siddharth Agarwal <sid0@fb.com> [Sun, 29 Mar 2015 19:23:05 -0700] rev 24538
dirstate: factor out code to discover normalized path In upcoming patches we're going to reuse this code. The storemap is currently always the foldmap, but will vary in future patches.
Tue, 31 Mar 2015 11:11:39 -0400 dirstate: don't require exact case when adding dirs on icasefs (issue4578) stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 31 Mar 2015 11:11:39 -0400] rev 24537
dirstate: don't require exact case when adding dirs on icasefs (issue4578) We don't require it when adding files on a case insensitive filesystem, so don't require it to add directories for consistency. The problem with the previous code was that _walkexplicit() was only returning the normalized directory. The file(s) in the directory are then appended, and passed to the matcher. But if the user asks for 'capsdir1/capsdir', the matcher will not accept 'CapsDir1/CapsDir/AbC.txt', and the name is dropped. Matching based on the non-normalized name is required. If not normalizing, skip the extra string building for efficiency. '.' is replaced with '' so that the path being tested when no file is specified, isn't prefixed with './' (and therefore fail the match).
Tue, 31 Mar 2015 11:58:14 -0700 filemerge: clean up language in mergemarkertemplate help stable
Nathan Goldbaum <ngoldbau@ucsc.edu> [Tue, 31 Mar 2015 11:58:14 -0700] rev 24536
filemerge: clean up language in mergemarkertemplate help
Tue, 31 Mar 2015 14:27:45 -0400 color: fix crash in cmd.exe
Matt Harbison <matt_harbison@yahoo.com> [Tue, 31 Mar 2015 14:27:45 -0400] rev 24535
color: fix crash in cmd.exe When 'term' is None because it isn't in the environment, don't iterate over it. Unfortunately, unsetting $TERM or exporting it as '' doesn't work in the tests, so there's no way to simulate cmd.exe in the test suite.
Wed, 18 Mar 2015 21:44:25 -0700 log: prefer 'wctx' over 'pctx' for working context
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Mar 2015 21:44:25 -0700] rev 24534
log: prefer 'wctx' over 'pctx' for working context
Tue, 31 Mar 2015 08:31:42 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 31 Mar 2015 08:31:42 -0500] rev 24533
merge with stable
Tue, 31 Mar 2015 08:04:42 -0500 tags: remove scary message about corrupt tags cache
Matt Mackall <mpm@selenic.com> [Tue, 31 Mar 2015 08:04:42 -0500] rev 24532
tags: remove scary message about corrupt tags cache Caches should be transparent. If a cache is damaged, it should silently be rebuilt, much like if it were invalid. No one seems to have ever hit this in the wild.
Sun, 29 Mar 2015 19:15:04 +0200 hgk: use switch instead of a less efficient if/elseif/if
Andrew Shadura <andrew@shadura.me> [Sun, 29 Mar 2015 19:15:04 +0200] rev 24531
hgk: use switch instead of a less efficient if/elseif/if
Sun, 29 Mar 2015 19:12:08 +0200 hgk: set distinct fill and outline colour for non-public and obsolete changesets
Andrew Shadura <andrew@shadura.me> [Sun, 29 Mar 2015 19:12:08 +0200] rev 24530
hgk: set distinct fill and outline colour for non-public and obsolete changesets
Sun, 29 Mar 2015 18:44:53 +0200 hgk: show secret changesets differently (shape and label)
Andrew Shadura <andrew@shadura.me> [Sun, 29 Mar 2015 18:44:53 +0200] rev 24529
hgk: show secret changesets differently (shape and label)
Fri, 27 Mar 2015 20:41:30 -0700 manifestv2: implement slow readdelta() without revdiff
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Mar 2015 20:41:30 -0700] rev 24528
manifestv2: implement slow readdelta() without revdiff For manifest v2, revlog.revdiff() usually does not provide enough information to produce a manifest. As a simple workaround, implement readdelta() by reading both the old and the new manifest and use manifest.diff() to find the difference. This is several times slower than the current readdelta() for v1 manifests, but there seems to be no other simple option, and this is still much faster than returning the full manifest (at least for verify).
Fri, 27 Mar 2015 17:07:24 -0700 manifestv2: disable fastdelta optimization
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Mar 2015 17:07:24 -0700] rev 24527
manifestv2: disable fastdelta optimization We may add support for the fastdelta optimization for manifest v2 at a later point, but let's disable it for now, so we don't have to implement it right away.
Fri, 27 Mar 2015 16:19:44 -0700 manifestv2: add (unused) config option
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Mar 2015 16:19:44 -0700] rev 24526
manifestv2: add (unused) config option With tree manifests, hashes will change anyway, so now is a good time to also take up the old plans of a new manifest format. While there should be little or no reason to use tree manifests with the current manifest format (v1) once the new format (v2) is supported, we'll try to keep the two dimensions (flat/tree and v1/v2) separate. In preparation for adding a the new format, let's add configuration for it and propagate that configuration to the manifest revlog subclass. The new configuration ("experimental.manifestv2") says in what format to write the manifest data. We may later add other configuration to choose how to hash it, either keeping the v1 hash for BC or hashing the v2 content. See http://mercurial.selenic.com/wiki/ManifestV2Plan for more details.
Fri, 27 Mar 2015 15:37:46 -0700 manifest: extract method for creating manifest text
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Mar 2015 15:37:46 -0700] rev 24525
manifest: extract method for creating manifest text Similar to the previous change, this one extracts a method for producing a manifest text from an iterator over (path, node, flags) tuples.
Fri, 27 Mar 2015 15:02:43 -0700 manifest: extract method for parsing manifest
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Mar 2015 15:02:43 -0700] rev 24524
manifest: extract method for parsing manifest By extracting a method that generates (path, node, flags) tuples, we can reuse the code for parsing a manifest without doing it via a _lazymanifest like treemanifest currently does. It also prepares for parsing the new manifest format. Note that this makes parsing into treemanifest slower, since the parsing is now always done in pure Python. Since treemanifests will be expected (or even forced) to be used only with the new manifest format, parsing via _lazymanifest was not an option anyway.
Sun, 29 Mar 2015 18:28:48 -0700 dirstate._walkexplicit: don't bother normalizing '.'
Siddharth Agarwal <sid0@fb.com> [Sun, 29 Mar 2015 18:28:48 -0700] rev 24523
dirstate._walkexplicit: don't bother normalizing '.' The overwhelmingly common case is running commands like 'hg diff' with no arguments. Therefore the only file that'll be listed is the root directory. Normalizing that's just a waste of time. This means that for a plain 'hg diff' we'll never need to construct the foldmap, saving us a significant chunk of time. On case-insensitive HFS+ on OS X, for a large repository with over 200,000 files, this brings down 'hg diff' from 2.97 seconds to 2.36.
Sun, 29 Mar 2015 23:28:30 -0700 dirstate._walkexplicit: drop normpath calls
Siddharth Agarwal <sid0@fb.com> [Sun, 29 Mar 2015 23:28:30 -0700] rev 24522
dirstate._walkexplicit: drop normpath calls The paths the matcher returns are normalized already.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip