Fri, 12 Oct 2018 18:20:17 +0200 py3: encode str to bytes
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 18:20:17 +0200] rev 40202
py3: encode str to bytes These fields are str on Python 2 and 3. This module doesn't import any Mercurial modules. So I just did the str -> bytes inline. Differential Revision: https://phab.mercurial-scm.org/D5010
Fri, 12 Oct 2018 19:00:24 +0200 py3: sprinkle statprof.py with utf-8 encoding
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 19:00:24 +0200] rev 40201
py3: sprinkle statprof.py with utf-8 encoding Trying to chase the long tail of unicode badness in this file due to frame / code objects holding str everywhere. Differential Revision: https://phab.mercurial-scm.org/D5016
Fri, 12 Oct 2018 19:17:22 +0200 py3: flush stdout
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 19:17:22 +0200] rev 40200
py3: flush stdout This avoids buffering due to mixed print() and sys.stdout.write() by profiling code. And with this, test-profile.t passes on Python 3 \o/. Honestly, I'd be shocked if there weren't more Python 3 encoding issues lingering in the profiling code. That code isn't super high quality and doesn't seem to have thorough test coverage. Differential Revision: https://phab.mercurial-scm.org/D5018
Fri, 12 Oct 2018 19:07:12 +0200 py3: use raw strings in statprof.py
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 19:07:12 +0200] rev 40199
py3: use raw strings in statprof.py This allows main() and argument parsing to work. Differential Revision: https://phab.mercurial-scm.org/D5017
Fri, 12 Oct 2018 18:51:10 +0200 py3: switch from print(..., file=) to write()
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 18:51:10 +0200] rev 40198
py3: switch from print(..., file=) to write() Because Python 3's print() doesn't like bytes. Differential Revision: https://phab.mercurial-scm.org/D5015
Fri, 12 Oct 2018 18:40:32 +0200 py3: use %d in a few places
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 18:40:32 +0200] rev 40197
py3: use %d in a few places Differential Revision: https://phab.mercurial-scm.org/D5014
Fri, 12 Oct 2018 18:37:42 +0200 py3: use raw strings for stack names
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 18:37:42 +0200] rev 40196
py3: use raw strings for stack names These are used for simple compares. We don't need to normalize to bytes. As part of this, I expanded a set literal so entries are 1 per line. Differential Revision: https://phab.mercurial-scm.org/D5013
Fri, 12 Oct 2018 18:30:40 +0200 py3: use sysbytes for converting code attributes
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 18:30:40 +0200] rev 40195
py3: use sysbytes for converting code attributes Differential Revision: https://phab.mercurial-scm.org/D5012
Fri, 12 Oct 2018 18:26:10 +0200 py3: use write() instead of print()
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 18:26:10 +0200] rev 40194
py3: use write() instead of print() Because print() expects str and we want to write bytes. There should be no functional changes as part of this. Differential Revision: https://phab.mercurial-scm.org/D5011
Fri, 12 Oct 2018 17:35:54 +0200 py3: use %d to format ints
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 17:35:54 +0200] rev 40193
py3: use %d to format ints Differential Revision: https://phab.mercurial-scm.org/D5009
Fri, 12 Oct 2018 17:31:10 +0200 py3: convert sorting field to sysstr
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 17:31:10 +0200] rev 40192
py3: convert sorting field to sysstr This is used as part of an attribute name check and needs to be native str. Differential Revision: https://phab.mercurial-scm.org/D5008
Fri, 12 Oct 2018 17:25:02 +0200 py3: encode json output to bytes and use write()
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 17:25:02 +0200] rev 40191
py3: encode json output to bytes and use write() Differential Revision: https://phab.mercurial-scm.org/D5007
Fri, 12 Oct 2018 17:48:40 +0000 absorb: prompt user to accept absorb changes by default
Mark Thomas <mbthomas@fb.com> [Fri, 12 Oct 2018 17:48:40 +0000] rev 40190
absorb: prompt user to accept absorb changes by default Change the default absorb behaviour to print the changes out and then prompt the user if they want to absorb the changes or not. Providing the `-p` option still prints the result and exits. A new `-a` option is provided which applies the changes without printing them, giving the equivalent of the old behaviour. Differential Revision: https://phab.mercurial-scm.org/D4999
Fri, 12 Oct 2018 15:46:52 +0000 templatefuncs: add truncate parameter to pad
Mark Thomas <mbthomas@fb.com> [Fri, 12 Oct 2018 15:46:52 +0000] rev 40189
templatefuncs: add truncate parameter to pad Add a truncate option to pad that additionally truncates the text to the pad width if it is wider. Since color codes can cause a problem with this, when the text is truncated, the color codes are also stripped. Users of the truncate option should label the text outside the pad. Differential Revision: https://phab.mercurial-scm.org/D5000
Fri, 12 Oct 2018 15:46:51 +0000 absorb: print summary of changesets affected
Mark Thomas <mbthomas@fb.com> [Fri, 12 Oct 2018 15:46:51 +0000] rev 40188
absorb: print summary of changesets affected Differential Revision: https://phab.mercurial-scm.org/D4998
Fri, 12 Oct 2018 13:35:58 +0000 absorb: use a formatter to generate output
Mark Thomas <mbthomas@fb.com> [Fri, 12 Oct 2018 13:35:58 +0000] rev 40187
absorb: use a formatter to generate output Change absorb to use a formatter to generate its output. This allows the use of templates to customize the output. Differential Revision: https://phab.mercurial-scm.org/D4997
Fri, 12 Oct 2018 12:31:17 -0400 tests: fix up test-bad-extension.t's inline extension
Augie Fackler <augie@google.com> [Fri, 12 Oct 2018 12:31:17 -0400] rev 40186
tests: fix up test-bad-extension.t's inline extension Upcoming patches will be simpler, I think. Differential Revision: https://phab.mercurial-scm.org/D5003
Fri, 12 Oct 2018 11:44:27 -0400 polib: update to latest release 1.0.7 (upstream rev d75ce6dbbc2a)
Augie Fackler <augie@google.com> [Fri, 12 Oct 2018 11:44:27 -0400] rev 40185
polib: update to latest release 1.0.7 (upstream rev d75ce6dbbc2a) # no-check-commit third-party code that doesn't match our style Differential Revision: https://phab.mercurial-scm.org/D5001
Fri, 12 Oct 2018 10:01:09 -0400 tests: glob away some annoying py3 differences
Augie Fackler <augie@google.com> [Fri, 12 Oct 2018 10:01:09 -0400] rev 40184
tests: glob away some annoying py3 differences Differential Revision: https://phab.mercurial-scm.org/D4994
Fri, 12 Oct 2018 10:00:43 -0400 tests: fix a repr on python3 in test-extension.t
Augie Fackler <augie@google.com> [Fri, 12 Oct 2018 10:00:43 -0400] rev 40183
tests: fix a repr on python3 in test-extension.t Differential Revision: https://phab.mercurial-scm.org/D4993
Fri, 12 Oct 2018 10:00:14 -0400 tests: so many b prefixes in test-extension.t
Augie Fackler <augie@google.com> [Fri, 12 Oct 2018 10:00:14 -0400] rev 40182
tests: so many b prefixes in test-extension.t # skip-blame because it's b prefixes Differential Revision: https://phab.mercurial-scm.org/D4992
Fri, 12 Oct 2018 09:59:11 -0400 tests: ensure print() statements in test-extension.t all flush
Augie Fackler <augie@google.com> [Fri, 12 Oct 2018 09:59:11 -0400] rev 40181
tests: ensure print() statements in test-extension.t all flush Differential Revision: https://phab.mercurial-scm.org/D4991
Fri, 12 Oct 2018 16:19:21 +0200 revlog: update pure nodecache start lookup offset on insertion
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 12 Oct 2018 16:19:21 +0200] rev 40180
revlog: update pure nodecache start lookup offset on insertion test-storage.py is failing in pure builds because the population of the node cache isn't accounting for the new starting offset after a revlog insertion. This commit updates the node cache start offset to account for insertions. I'm not 100% convinced this is the ideal solution. But it works and seems correct. Differential Revision: https://phab.mercurial-scm.org/D4996
Wed, 03 Oct 2018 13:57:42 -0700 exchangev2: use filesdata
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 03 Oct 2018 13:57:42 -0700] rev 40179
exchangev2: use filesdata filesdata is a more efficient mechanism for bulk fetching files data for a range of changesets. Let's use it in exchangev2. With this change, a client performing a full clone of mozilla-unified transmits substantially fewer bytes across the wire: before: 139,124,863 bytes sent after: 20,522,499 bytes sent The bulk of the remaining bytes is likely the transfer of ~1M nodes for changesets and manifests. We can eliminate this by making requests in terms of node ranges instead of explicit node lists... Differential Revision: https://phab.mercurial-scm.org/D4982
Wed, 03 Oct 2018 12:54:39 -0700 wireprotov2: define and implement "filesdata" command
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 03 Oct 2018 12:54:39 -0700] rev 40178
wireprotov2: define and implement "filesdata" command Previously, the only way to access file revision data was the "filedata" command. This command is useful to have. But, it only allowed resolving revision data for a single file. This meant that clients needed to send 1 command for each tracked path they were seeking data on. Furthermore, those commands would need to enumerate the exact file nodes they wanted data for. This approach meant that clients were sending a lot of data to remotes in order to request file data. e.g. if there were 1M file revisions, we'd need at least 20,000,000 bytes just to encode file nodes! Many clients on the internet don't have that kind of upload capacity. In order to limit the amount of data that clients must send, we'll need more efficient ways to request repository data. This commit defines and implements a new "filesdata" command. This command allows the retrieval of data for multiple files by specifying changeset revisions and optional file patterns. The command figures out what file revisions are "relevant" and sends them in bulk. The logic around choosing which file revisions to send in the case of haveparents not being set is overly simple and will over-send files. We will need more smarts here eventually. (Specifically, the client will need to tell the server which revisions it knows about.) This work is deferred until a later time. Differential Revision: https://phab.mercurial-scm.org/D4981
Tue, 02 Oct 2018 10:31:36 -0700 wireprotov2: extract file object emission to own function
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 02 Oct 2018 10:31:36 -0700] rev 40177
wireprotov2: extract file object emission to own function An upcoming commit will introduce another caller. Differential Revision: https://phab.mercurial-scm.org/D4980
Mon, 08 Oct 2018 18:17:12 -0700 wireprotov2: change how revisions are specified to changesetdata
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 18:17:12 -0700] rev 40176
wireprotov2: change how revisions are specified to changesetdata Right now, we have a handful of arguments for specifying the revisions whose data should be returned. Defining how all these arguments interact when various combinations are present is difficult. This commit establishes a new, generic mechanism for specifying revisions. Instead of a hodgepodge of arguments defining things, we have a list of dicts that specify revision selectors. The final set of revisions is a union of all these selectors. We implement support for specifying revisions based on: * An explicit list of changeset revisions * An explicit list of changeset revisions plus ancestry depth * A DAG range between changeset roots and heads If you squint hard enough, this problem has already been solved by revsets. But I'm reluctant to expose revsets to the wire protocol because that would require servers to implement a revset parser. Plus there are security and performance implications: the set of revision selectors needs to be narrowly and specifically tailored for what is appropriate to be executing on a server. Perhaps there would be a way for us to express the "parse tree" of a revset query, for example. I'm not sure. We can explore this space another time. For now, the new mechanism should bring sufficient flexibility while remaining relatively simple. The selector "types" are prefixed with "changeset" because I plan to add manifest and file-flavored selectors as well. This will enable us to e.g. select file revisions based on a range of changeset revisions. Differential Revision: https://phab.mercurial-scm.org/D4979
Mon, 08 Oct 2018 17:54:14 -0700 wireprotov2: stop sending phase updates for base revisions
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:54:14 -0700] rev 40175
wireprotov2: stop sending phase updates for base revisions This feature is broken and doesn't work properly in all scenarios. e.g. if we have the following DAGs: client server D draft C draft C draft B draft B public A public A public The current code would only send the phase data for C. The client wouldn't see that B moved from draft to public. This feature will be restored in a future commit. For now, it is making refactoring of how revisions are specified in the wire protocol a bit difficult... Differential Revision: https://phab.mercurial-scm.org/D4978
Thu, 11 Oct 2018 09:47:52 +0200 debugcommands: support wrapping long lines
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 11 Oct 2018 09:47:52 +0200] rev 40174
debugcommands: support wrapping long lines If a line within a block is indented more than the line that came before, we automatically concatenate it with the previous line. This allows us to pretty format data. This will make tests easier to read. At some point we may just want to evaluate entire blocks as Python code or something, as even with this change, things aren't perfect, as we can't e.g. have formatting like: foo eval:[ True ] But this is strictly better than before, where we couldn't wrap long lines. Differential Revision: https://phab.mercurial-scm.org/D4977
Wed, 03 Oct 2018 13:17:00 -0700 exchangev2: honor server advertised manifestdata recommended batch size
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 03 Oct 2018 13:17:00 -0700] rev 40173
exchangev2: honor server advertised manifestdata recommended batch size Let's plug the client up to the server-advertised recommended batch size for manifestdata requests. Differential Revision: https://phab.mercurial-scm.org/D4976
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip