Gregory Szorc <gregory.szorc@gmail.com> [Sat, 13 May 2017 16:26:43 -0700] rev 32292
changelog: load pending file directly
When changelogs are written, a copy of the index (or inline revlog)
may be written to an 00changelog.i.a file to facilitate hooks and
other processes having access to the pending data before it is
finalized.
The way it works today, the localrepo class loads the changelog
like normal. Then, if it detects a pending transaction, it asks
the changelog class to load a pending changelog. The changelog
class looks for a 00changelog.i.a file. If it exists, it is
loaded and internal data structures on the new revlog class are
copied to the original instance.
The existing mechanism is inefficient because it loads 2 revlog
files. The index, node map, and chunk cache for 00changelog.i
are thrown away and replaced by those for 00changelog.i.a.
The existing mechanism is also brittle because it is a layering
violation to access the data structures being accessed. For example,
the code copies the "chunk cache" because for inline revlogs
this cache contains the raw revision chunks and allows the original
changelog/revlog instance to access revision data for these pending
revisions. This whole behavior of course relies on the revlog
constructor reading the entirety of an inline revlog into memory
and caching it. That's why it is brittle. (I discovered all this
as part of modifying behavior of the chunk cache.)
This patch streamlines the loading of a pending 00changelog.i.a
revlog by doing it directly in the changelog constructor if told
to do so. When this code path is active, we no longer load the
00changelog.i file at all.
The only negative outcome I see from this change is if loading
00changelog.i was somehow facilitating a role. But I can't imagine
what that would be because we throw away its data (the index data
structures are replaced and inline revision data is replaced via
the chunk cache) and since 00changelog.i.a is a copy of
00changelog.i, file content should be identical, so there should
be no meaninful file integrity checking at play. I think this was
all just sub-optimal code.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Feb 2017 16:56:29 -0800] rev 32291
cleanup: use set literals
We no longer support Python 2.6, so we can now use set literals.
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 May 2017 04:51:25 +0530] rev 32290
py3: convert date and format arguments str before passing in time.strptime
time.strptime() raises ValueError if the arguments are not str.
Source Code: https://hg.python.org/cpython/file/3.5/Lib/_strptime.py#l307
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 04 May 2017 00:24:21 +0530] rev 32289
py3: convert kwargs' keys to str using pycompat.strkwargs
Jun Wu <quark@fb.com> [Sun, 14 May 2017 09:38:06 -0700] rev 32288
verify: add a config option to skip certain flag processors
Previously, "hg verify" verifies everything, which could be undesirable when
there are expensive flag processor contents.
This patch adds a "verify.skipflags" developer config. A flag processor will
be skipped if (flag & verify.skipflags) == 0.
In the LFS usecase, that means "hg verify --config verify.skipflags=8192"
will not download all LFS blobs, which could be too large to be stored
locally.
Note: "renamed" is also skipped since its default implementation may call
filelog.data() which will trigger the flag processor.
Durham Goode <durham@fb.com> [Mon, 15 May 2017 09:35:27 -0700] rev 32287
changegroup: add bundlecaps back
Commit
282b288aa20c333c removed the unused bundlecaps argument from the
changegroup code. While it is unused in core Mercurial, it was an important
feature for the remotefilelog extension because it allowed the exchange layer to
communicate to the changegroup packer that this was a shallow repo and that
filelogs should not be included. Without bundlecaps, there is currently no other
way to pass that information along without a more extensive refactor of
exchange, bundle, and changegroup code.
This patch backs out the original removal, and merges it with some recent
changes to changegroup apis.
Jun Wu <quark@fb.com> [Wed, 10 May 2017 16:17:58 -0700] rev 32286
flagprocessor: add a fast path when flags is 0
When flags is 0, _processflags could be a no-op instead of iterating through
the flag bits.
Kostia Balytskyi <ikostia@fb.com> [Sat, 13 May 2017 14:52:29 -0700] rev 32285
shelve: make shelvestate use simplekeyvaluefile
Currently shelvestate uses line ordering to differentiate fields. This
makes it hard for extensions to wrap shelve, since if two alternative
versions of code add a new line, correct merging is going to be problematic.
simplekeyvaluefile was introduced fot this purpose specifically.
After this patch:
- shelve will always write a simplekeyvaluefile
- unshelve will check the first line of the file for a version, and if the
version is 1, will read it in a position-based way, if the version is 2,
will read it in a key-value way
As discussed with Yuya previously, this will be able to handle old-style
shelvedstate files, but old Mercurial versions will fail on the attempt to
read shelvedstate file of version 2 with a self-explanatory message:
'abort: this version of shelve is incompatible with the version used
in this repo'
Kostia Balytskyi <ikostia@fb.com> [Sun, 14 May 2017 14:15:07 -0700] rev 32284
shelve: refactor shelvestate loading
This is a preparatory patch which separates file reading from the
minimal validation we have (like turning version into int and
checking that this version is supported). The purpose of this patch
is to be able to read statefile form simplekeyvaluefile, which is
implemented in the following patch.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 11 May 2017 22:33:45 -0400] rev 32283
extdiff: copy back execbit-only changes to the working directory
Some tools like BeyondCompare allow the file mode to be changed. The change
was previously applied if the content of the file changed (either according to
size or mtime), but was not being copied back for a mode-only change. That
would seem to indicate handling this in an 'elif' branch, but I opted not to in
order to avoid copying back the mode without the content changes when mtime and
size are unchanged. (Yes, that's a rare corner case, but all the more reason
not to have a subtle difference in behavior.)
The only way I can think to handle this undetected change is to set each file in
the non-wdir() snapshot to readonly, and check for that attribute (as well as
mtime) when deciding to copy back. That would avoid the overhead of copying the
whole file when only the mode changed. But a chmod in a diff tool is likely
rare. See also
affd753ddaf1.