Matt Mackall <mpm@selenic.com> [Sun, 11 Jan 2015 14:32:56 -0600] rev 23794
readmarkers: drop another conditional
Matt Mackall <mpm@selenic.com> [Sat, 10 Jan 2015 21:28:15 -0600] rev 23793
readmarkers: drop a conditional
Matt Mackall <mpm@selenic.com> [Sat, 10 Jan 2015 21:27:29 -0600] rev 23792
readmarkers: add some whitespace
Matt Mackall <mpm@selenic.com> [Sat, 10 Jan 2015 21:25:07 -0600] rev 23791
readmarkers: combine parent conditionals
Matt Mackall <mpm@selenic.com> [Sat, 10 Jan 2015 21:24:45 -0600] rev 23790
readmarkers: drop temporary substring assignments
Assignments are expensive in inner loops
Matt Mackall <mpm@selenic.com> [Sat, 10 Jan 2015 21:18:31 -0600] rev 23789
util: introduce unpacker
This allows taking advantage of Python 2.5+'s struct.Struct, which
provides a slightly faster unpack due to reusing formats. Sadly,
.unpack_from is significantly slower.
Matt Mackall <mpm@selenic.com> [Sat, 10 Jan 2015 21:13:10 -0600] rev 23788
perf: add a configurable sleep on startup
This is intended to counteract power management by giving a consistent
idle period before test runs.
Mads Kiilerich <madski@unity3d.com> [Thu, 08 Jan 2015 00:01:03 +0100] rev 23787
revset: use localrepo revbranchcache for branch name filtering
Branch name filtering in revsets was expensive. For every rev it created a
changectx and called .branch() which retrieved the branch name from the
changelog.
Instead, use the revbranchcache.
The revbranchcache is used read-only. The revset implementation with generators
and callbacks makes it hard to figure out when we are done using/updating the
cache and could write it back. It would also be 'tricky' to lock the repo for
writing from within a revset execution. Finally, the branchmap update will
usually make sure that the cache is updated before any revset can be run.
The revbranchcache is used without any locking but is short-lived and used in a
tight loop where we can assume that the changelog doesn't change ... or where
it not is relevant to us if it does.
perfrevset 'branch(mobile)' on mozilla-central.
Before:
! wall 10.989637 comb 10.970000 user 10.940000 sys 0.030000 (best of 3)
After, no cache:
! wall 7.368656 comb 7.370000 user 7.360000 sys 0.010000 (best of 3)
After, with cache:
! wall 0.528098 comb 0.530000 user 0.530000 sys 0.000000 (best of 18)
The performance improvement even without cache come from being based on
branchinfo on the changelog instead of using ctx.branch().
Some tests are added to verify that the revbranchcache works and keep an eye on
when the cache files actually are updated.
Mads Kiilerich <madski@unity3d.com> [Thu, 08 Jan 2015 00:01:03 +0100] rev 23786
branchmap: use revbranchcache when updating branch map
The revbranchcache is read on demand before it will be used for updating the
branch map. It is written back when the branchmap is written and it will thus
use the same locking as branchmap. The revbranchcache instance is short-lived;
it is only stored in the branchmap from .update() is invoked and until .write()
is invoked. Branchmap already assume that the repo is locked in that case.
The use of revbranchcache for branch map updates will make sure that the
revbranchcache "always" is kept up-to-date.
The perfbranchmap benchmark is somewhat bogus, especially when we can see that
the caching makes a significant difference between the realistic case of a
first run and the rare case of rerunning it with a full cache. Here are some
'base' numbers on mozilla-central:
Before:
! wall 6.912745 comb 6.910000 user 6.840000 sys 0.070000 (best of 3)
After - initial, cache is empty:
! wall 7.792569 comb 7.790000 user 7.720000 sys 0.070000 (best of 3)
After - cache is full:
! wall 0.879688 comb 0.880000 user 0.870000 sys 0.010000 (best of 4)
The overhead when running with empty cache comes from checking, missing and
updating it every time.
Most of the performance improvement comes from not having to extract the branch
info from the changelog. The last doubling of performance comes from no longer
having to convert all branch names to local encoding but reuse the few already
converted branch names.
On the hg repo:
Before:
! wall 0.715703 comb 0.710000 user 0.710000 sys 0.000000 (best of 14)
After:
! wall 0.105489 comb 0.110000 user 0.110000 sys 0.000000 (best of 87)
Mads Kiilerich <madski@unity3d.com> [Thu, 08 Jan 2015 00:01:03 +0100] rev 23785
branchcache: introduce revbranchcache for caching of revision branch names
It is expensive to retrieve the branch name of a revision. Very expensive when
creating a changectx and calling .branch() every time - slightly less when
using changelog.branchinfo().
Now, to speed things up, provide a way to cache the results on disk in an
efficient format. Each branchname is assigned a number, and for each revision
we store the number of the corresponding branch name. The branch names are
stored in a dedicated file which is strictly append only.
Branch names are usually reused across several revisions, and the total list of
branch names will thus be so small that it is feasible to read the whole set of
names before using the cache. It will however do that it might be more
efficient to use the changelog for retrieving the branch info for a single
revision.
The revision entries are stored in another file. This file is usually append
only, but if the repository has been modified, the file will be truncated and
the relevant parts rewritten on demand.
The entries for each revision are 8 bytes each, and the whole revision file
will thus be 1/8 of 00changelog.i.
Each revision entry contains the first 4 bytes of the corresponding node hash.
This is used as a check sum that always is verified before the entry is used.
That check is relatively expensive but it makes sure history modification is
detected and handled correctly. It will also detect and handle most revision
file corruptions.
This is just a cache. A new format can always be introduced if other
requirements or ideas make that seem like a good idea. Rebuilding the cache is
not really more expensive than it was to run for example 'hg log -b branchname'
before this cache was introduced.
This new method is still unused but promise to make some operations several
times faster once it actually is used.
Abandoning Python 2.4 would make it possible to implement this more efficiently
by using struct classes and pack_into. The Python code could probably also be
micro optimized or it could be implemented very efficiently in C where it would
be easy to control the data access.
Anton Shestakov <engored@ya.ru> [Fri, 09 Jan 2015 22:53:38 +0800] rev 23784
hgweb: move archive entries outside of <li> in monoblue style
archiveentry already includes surrounding <li></li>, so putting archive entries
inside <li> element produced incorrect markup.
Anton Shestakov <engored@ya.ru> [Fri, 09 Jan 2015 15:24:55 +0800] rev 23783
hgweb: add searchhint to templates/coal/map
coal style uses every template (except header.tmpl) directly from paper style,
but doesn't use paper/map file. Elements defined in such map files are used in
templates as you would expect. For example, paper/search.tmpl contains
'{searchhint}' and template engine replaces that with the actual hint. But when
coal style reuses paper/search.tmpl, it needs to define searchhint in its map
file as well, or template engine will not find it. So let's copy it from
paper/map to coal/map.
Before this change, if the coal style was selected, the hint for the search
field in page header was present, but it was completely empty. Although the
absence of searchhint in coal/map produced no error.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 30 Dec 2014 21:12:52 -0500] rev 23782
largefiles: enable subrepo support for remove
Previously, remove failed when operating on a largefile in a subrepo, stating
that the file is untracked.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Jan 2015 21:36:12 -0800] rev 23781
transplant: properly skip empty changeset (
issue4423)
If resolving a merge conflict result in an empty changesets, we now properly
skip the changeset instead of crashing.
Original patch from Robert Collins <robertc@robertcollins.net>.
Mathias De Maré <mathias.demare@gmail.com> [Thu, 08 Jan 2015 21:30:22 +0100] rev 23780
color: add support for colorizing git subrepo diffs
Matt Harbison <matt_harbison@yahoo.com> [Thu, 08 Jan 2015 23:33:56 -0500] rev 23779
tests: fix test-casefolding.t output
This change started with
a387b0390082.
Mike Edgar <adgar@google.com> [Fri, 12 Dec 2014 17:42:14 +0000] rev 23778
synthrepo: new filenames must not also be new directories, and vice-versa
When generating many new files into a set of many possible new directories,
there is the possibility that the same path is chosen as both file and
directory. How likely this is depends on the size of the dictionary used,
the generated directory structure and the number of generated files.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 08 Jan 2015 13:29:06 -0800] rev 23777
status: don't override _buildstatus() in workingcommitctx
Now that the caching into _status is done in
workingctx._dirstatestatus(), which workingcommitctx._dirstatestatus()
does not call, there is no caching to prevent in _buildstatus(), so
stop overriding it.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 08 Jan 2015 13:12:44 -0800] rev 23776
status: cache dirstate status in _dirstatestatus()
Since it's only the dirstate status we cache, it makes more sense to
cache it in the _dirstatestatus() method. Note that this change means
the dirstate status will also be cached when status is requested
between the working copy and some other revision, while we currently
only cache the result if exactly the status between the working copy
and its parent is requested.
Sean Farley <sean.michael.farley@gmail.com> [Thu, 16 Oct 2014 21:49:28 -0700] rev 23775
localrepo: add ignoremissing parameter to branchtip
Previously, in the namespaces api, the only caller of branchtip was singlenode
which happened to raise the same exception that branchtip raised: KeyError.
This is a minor change but will allow upcoming patches to use repo.branchtip to
not raise an exception if a branch doesn't exist. After that, it will be
possible for extensions to use the namespace api in a stable way.
Sean Farley <sean.michael.farley@gmail.com> [Mon, 15 Dec 2014 14:46:04 -0800] rev 23774
namespaces: add method to return a list of nodes for a given name
This is a helpful method that some extensions can make use of (e.g. for custom
revsets); currently not used in core.
Sean Farley <sean.michael.farley@gmail.com> [Tue, 21 Oct 2014 19:49:23 -0700] rev 23773
namespaces: add test for log
Now that we have enough features in the namespaces api, we add a test for it.
Sean Farley <sean.michael.farley@gmail.com> [Fri, 17 Oct 2014 09:26:37 -0700] rev 23772
log: use new namespaces api to display names
The only caveat here is that branches must be displayed first due to backwards
compatibility. The order of namespaces is defined to be the 'update' order
which, unfortunately, is not the same as log output order.
It's worth mentioning that the log output is still translated the same as
before since we are formating our strings the same way:
# i18n: column positioning for "hg log"
_("bookmark: %s\n") % bookmark
becomes
tname = _(("%s:" % ns.templatename).ljust(13) + "%s\n") % name
when name == 'bookmark'. The ljust(13) keeps the strings and whitespace equal.
Adding a new namespace is even easier now because the log output code doesn't
need to change. A future programmer would just need to add the string to the
corresponding .po file (which is the same as they would have had to do
previously).
Sean Farley <sean.michael.farley@gmail.com> [Wed, 31 Dec 2014 16:50:19 -0600] rev 23771
tests: add a i18n translation test for log output
Upcoming patches will change the way that log output is generated so we add a
test to ensure that the words 'branches', 'bookmarks', and 'tags' are still
translated.
Durham Goode <durham@fb.com> [Fri, 09 Jan 2015 11:21:29 -0800] rev 23770
filectx: fix annotate to not directly instantiate filectx
28a302e9225d changed basefilectx.annotate() to directly instantiate new
filectx's instead of going through self.filectx(), this breaks extensions that
replace the filectx class, and would also break future uses that would need
memfilectx's.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 31 Dec 2014 18:39:41 -0500] rev 23769
largefiles: don't print files as both large and normal in addremove dryruns
Matt Harbison <matt_harbison@yahoo.com> [Wed, 31 Dec 2014 18:31:18 -0500] rev 23768
largefiles: return the list of added files from addlargefiles()
This will be used to exclude largefile candidates from the normal file matcher,
which will allow add and addremove dryruns to not print a file as both a normal
and a large file.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 28 Nov 2014 21:44:41 -0500] rev 23767
largefiles: align the output messages for an added file with core methods
Core addremove prints the file relative to cwd only if patterns are provided to
the command. Core add always prints relative to cwd. Also, both methods print
the subrepo prefix when needed. The 'already a largefile' doesn't have an
analog in core, but follows the same rules for consistency.