tests: update test-check-py3-compat.t output in the py3exe branch This hasn't been maintained in a while, it looks like. Differential Revision: https://phab.mercurial-scm.org/D4289

overlayworkingctx: fix exception in metadata-only inmemory merges (issue5960) If there was a metadata-only mutation, such as +x or -x on a file, we would create a cache entry with None for data, and this would cause problems later on when some code tried to run fctx.data() or similar, and was expecting a string. My original fix for this involved passing data=self._wrappedctx[path].data() in setflags(), but this version seems slightly better - this way, if we ever call write() and then call setflags(), we don't destroy the data that we wrote that's in the cache. I haven't verified that other fields aren't destroyed, such as date or flags :) Differential Revision: https://phab.mercurial-scm.org/D4287

filemerge: show actual capabilities of internal merge tools This information is useful to know which internal merge tools can be applied safely on binary files and/or symlinks.

filemerge: add config knob to check capabilities of internal merge tools For historical reason, Mercurial assumes capabilities of internal merge tools as below while examining rules to decide merge tool, regardless of actual capabilities of them. =============== ====== ======== specified via binary symlinks =============== ====== ======== --tool o o HGMERGE o o merge-patterns o (*) x (*) ui.merge x (*) x (*) =============== ====== ======== This causes: - unintentional internal merge tool is chosen for binary files via merge-patterns section of configuration file - explicit configuration of internal merge tool for symlinks is ignored unintentionally But on the other hand, simple "check capability strictly" might break backward compatibility (e.g. existing merge automations), because it changes the result of merge tool selection. Therefore, this patch adds config knob "merge.strict-capability-check" to control whether capabilities of internal merge tools should be checked strictly or not. If this configuration is true, capabilities of internal merge tools are checked strictly in (*) cases above.

filemerge: show warning if chosen tool has no binary files capability While matching patterns in "merge-patterns" configuration, Mercurial silently assumes that all merge tools have binary files capability. This implementation comes from 5af5f0f9d724 (or Mercurial 1.0). At failure of merging binary files with incorrect internal merge tool, there is no hint about this silent ignorance of binary files capability. This patch shows warning message, if chosen internal merge tool has no binary files capability. This will help users to investigate why a binary file isn't merged as expected.

filemerge: add the function to examine a capability of a internal tool For "symlink" and "binary" capabilities, _toolbool() can not examine these of internal merge tools strictly, because it examines only configurations in "merge-tools" section. Users can configure them explicitly as below for example, but this is not ordinary usage and not convenient: [merge-tools] :other.symlink = true :other.binary = true This patch adds hascapability() internal function, which can examine actual capabilities of a internal merge tool strictly. At this patch, hascapability() is still used with "strict=False". Subsequent patches use it with "strict=True".

filemerge: set actual capabilities of internal merge tools This information is used to detect actual capabilities of internal merge tools by subsequent patches. For convenience, this patch assumes that merge tools typed as "nomerge" have both binary files and symlinks capabilities.

help: describe more detail about capabilities while deciding merge tool "hg help merge-tools" describes as below: (internal merge tools) will by default not handle symlinks or binary files. But in some cases, Mercurial assumes that internal merge tools have one or both of these capabilities. "hg help merge-tools" also describes as below, for matching patterns in merge-patterns configuration section. But this is not sufficient. Here, binary capabilities of the merge tool are not considered. This patch describes more detail about capabilities while deciding merge tool.

tests: un-glob patchbomb test lines that were only globbing a hostname Differential Revision: https://phab.mercurial-scm.org/D4296

tests: force a stable hostname in patchbomb tests No visible output changes in this commit because everything is globbed away, but on Python 3 the stable hostname will mean that the headers don't trigger RFC2822 multi-line mode because they'll always be consistently short. Differential Revision: https://phab.mercurial-scm.org/D4295

patchbomb: allow using HGHOSTNAME to force a hostname I'll update run-tests.py to set this globally to stabilize some tests. The variable name is intentionally generic because I suspect we should generalize this to other tests. Differential Revision: https://phab.mercurial-scm.org/D4294

patchbomb: extract function for generating message-id Differential Revision: https://phab.mercurial-scm.org/D4293

rebase: cover restorestatus() by lock to prevent it from being updated To prevent it from being updated by another process `restorestatus()` is moved under lock. Differential Revision: https://phab.mercurial-scm.org/D4282

branchmap: load branchmap as an iterable This avoids reading all the file into memory if the cache turns out to be invalid. Differential Revision: https://phab.mercurial-scm.org/D4281

perf: time loading branchmap caches Differential Revision: https://phab.mercurial-scm.org/D4280

tests: add conditional output when simplestore extensions is loaded This drops the number of failures with this extension to 3. Differential Revision: https://phab.mercurial-scm.org/D4286

tests: conditionalize extension tests for extra extensions If extra extensions are loaded (e.g. via --extra-config-opt), the tests conditionalized in this commit fail in ways that are dependent on the extensions that are loaded. So let's skip them when that scenario is present. This drops the number of failures for the simplestorerepo.py extension to 4. Differential Revision: https://phab.mercurial-scm.org/D4285

commit: try hard to reuse p1 manifest if nothing changed This is all for commit reproducibility on "hg convert". With this change, p1 manifest is reused if ctx.files() *to be committed* is empty, and if new manifest entry is identical to p1. This is important property for "hg convert" since memctx.files() built from a convert source may be either a) more narrowed thanks to a committed ctx.files() which provides more accurate status, or b) containing redundant files because of sloppy filtering on e.g. octopus merge.

merge: add tests for commit with no content change It isn't easy to say when to reuse the p1 manifest. Basically, that's only when wctx.files() is empty, but we need to know that wctx.files() is not the same as repo['.'].files() after the commit. This patch adds several examples of commits with empty ctx/wctx.files(). I don't think this is exhaustive, but it contains at least one failure mode in which a converted repo result in a different hash. I also note that the manifest revlog does NOT follow the DAG shape of the changelog since p1 manifest is reused if wctx.files() is empty even at merge. I don't know whether it is intentional or not, but it's the behavior since 2011, 301725c3df9a "localrepo: reuse parent manifest in commitctx if no files have changed."

commit: add debug message regarding manifest reuse

mail: convert encoding.encoding to sysstr

mail: call s.decode('ascii') explicitly to see if s is an ascii bytes

mail: pass in addr to _addressencode() in bytes _addressencode() doesn't process a unicode addr well. For example, acc.encode('ascii') would raise UnicodeEncodeError if acc was a unicode. This patch temporarily restores the pre-952bf3c948f0 _addressencode(). Several tests would be broken on Python 3.

mail: remove redundant bytesurl() from addrlistencode() _addressencode() returns a bytes.

patchbomb: really use BytesGenerator API It wraps around Generator type.

byteify-strings: prevent "__name__ == '__main__'" from being transformed This was okay for import-time code transformer, but shouldn't be applied to source code.

merge with stable

rebase: turn off inmemory flag on --stop Guessing from the inline comment, "in-memory rebase is not compatible with resuming rebases", in-memory rebasing should be disabled.

rebase: use action variable to select things to do

rebase: consolidate check for --dry-run/--confirm on abort/stop/continue

rebase: consolidate check for --abort/--stop/--continue conflicts

rebase: do not set internal dryrun flag by --confirm This prepares for cleaning up option checking.

rebase: add test to show --stop moves bookmarks Added tests to show that --stop option moves bookmarks of rebased csets to their succs. Differential Revision: https://phab.mercurial-scm.org/D3982

rebase: include --stop option in documentation Differential Revision: https://phab.mercurial-scm.org/D3970

rebase: raise error for options conflicting with --stop Make sure --stop feature raise error for conflicting options --continue, --abort, --confirm, --dry-run. Tests are added to reflect the same. Differential Revision: https://phab.mercurial-scm.org/D3969

rebase: add --stop option to stop rebase at any point (issue5206) Before this patch, during a rebase if you get a point where you can't figure out what to do next, then either you had to complete your series or abandon all the work you have done during this rebase. Now, with this feature you can stop at any point by keeping the rebased csets and mark original csets as obsolete. And if you don't have evolution extension enabled then you can use --keep option as an alternative which will keep original csets too, instead of marking them obsolete. Differential Revision: https://phab.mercurial-scm.org/D3959

statprof: cleanup string construction Use string substitutions instead of string additions.

addremove: add associated color for the new labels We use classic color: green is added, red is removed.

remove: add a label for messages about removed files Keeping consistency between addremove and remove seems a good idea.

add: add a label for messages about added files Keeping consistency between addremove and add seems a good idea.

addremove: add labels for messages about added and removed files This is the first step to add color for add and remove output.

revlog: filter out "invalid" delta base candidates There are bases that we know won't produce a good delta chain. For example, if the base is already bigger than twice the size of the text we store, we know the resulting delta chain will never be valid. We might make the check a bit more powerful and generic in the future, but this looks a good start. In particular, empty file (size 0) will never find a good base, so we should stop spending time trying to find one.

revlog: use a symbolic constant for the deltas/text ration We are about to use it somewhere else, we should as well make it easier to access and change.

revlog: do not search for delta for empty content We won't find any useful base to store an empty text. So we should not even try to.

revlog: split and document good delta conditional The logic is still identical, but having each conditional on its own helps to document them and will help to edit them in the future.

revlog: skip over empty revision when looking for delta base There is no point in keeping an empty revision in the middle of a chain since they won't contribute any data. So we filter them out when looking for a valid base delta.

debugrevlog: display details about empty revision We now display details about the course of emptiness (empty text or empty delta).

debugrevlog: track empty revlog entries A revlog entry can be "empty" for two reasons: * the stored text is empty * we found another entry with the exact same content Tracking them separately make revlog content clearer.

debugrevlog: document some of the variable used This help to understand the code.

revlog: drop compatibility for `revlog.descendant` (API) As advertised, the method is dropped in 4.8.

context: drop compatibility for `context.descendant` (API) As advertised, the method is dropped in 4.8.

cmdutil: remove _updatecleanmsg() which is no longer used anywhere

cmdutil: fix weird indent in _mergemsg()

cext: fix a warning about differing const qualifiers on Windows The prototype takes a 'void *', but self->offsets is a 'const char **'. mercurial/cext/revlog.c(2011) : warning C4090: 'function' : different 'const' qualifiers

cext: fix most truncation warnings in revlog on Windows There's one more, and I'm not sure why it isn't being tripped on other platforms: mercurial/cext/revlog.c(430) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'char', possible loss of data

cext: fix Windows warning about implicit conversion of 32-bit shift to 64 bit mercurial/cext/revlog.c(1541) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift int ended?)

index: make capacity argument to nt_init be measured in revisions The nodetree's internal capacity field is measures in nodetree nodes, which is not something the caller should have to know about. Differential Revision: https://phab.mercurial-scm.org/D4166

index: avoid duplicating capacity-growth expression We were duplicating the "*2" instead of reusing it. It's overflow-safe to reuse as long as the growth factor (i.e. currently 2) is not larger than sizeof(nodetreenode) (currently 64 or 128). Differential Revision: https://phab.mercurial-scm.org/D4165

index: move check for too large capacity into nt_init() It's clearer to have the check just before the allocation happens. Differential Revision: https://phab.mercurial-scm.org/D4164

shortest: don't include nullid in disambigution revset As noted by Yuya in the review of D4118, the fact that the nodetree always contains the nullid is not what we want for the disambiguation case. It's not what the pure version of the code does. Note that the updated test also passes before this patch, but it wouldn't have passed in native-code mode once we start using the nodetree for disambiguating nodeid prefixes. Differential Revision: https://phab.mercurial-scm.org/D4163

index: don't include nullid in the internal "length" field This is a follow-up to 781b2720d2ac (index: don't include nullid in len(), 2018-07-20). I intentionally didn't update the "index stats", so it will also not include the space for nullid after this patch. Differential Revision: https://phab.mercurial-scm.org/D4162

tests: add test coverage for revlogindex[-1] which was previously missing Differential Revision: https://phab.mercurial-scm.org/D4184

context: safegaurd from 'lx' being passed as file flag in manifest Follows up for d558e53cd6b619d5f671a7580513bfc66a398eac. Differential Revision: https://phab.mercurial-scm.org/D4259

debugcommands: urlerror only has a read() method in Python 2 Differential Revision: https://phab.mercurial-scm.org/D4258

debugcommands: get_method should always return a sysstr Differential Revision: https://phab.mercurial-scm.org/D4257

stringutil: if we get a memoryview in escapestr, coerce it to bytes Otherwise we get an exception. Sadly, this manifesting deep inside the wireproto code, inside a future. For some reason the exception was /causing a hang/ rather than actually propagating out, which seems like it might merit some investigation in the future. Differential Revision: https://phab.mercurial-scm.org/D4256

debugcommands: fix a missing b prefix This wasn't causing any immediate problems because of the source transformer, but I noticed the inconsistency and it bugged me. # skip-blame just a b prefix Differential Revision: https://phab.mercurial-scm.org/D4255

wireprotohelpers: add missing b prefixes # skip-blame just b prefixes Differential Revision: https://phab.mercurial-scm.org/D4254

util: fix signature of setsockopt in socket observer The format string expected the result, callers all passed the result, but we didn't actually accept the result to this function. I swear I've looked at this code a dozen times trying to find the problem, and it was this simple all along. Differential Revision: https://phab.mercurial-scm.org/D4253

tests: port test-glog.t to Python 3 by using extracted printrevset Differential Revision: https://phab.mercurial-scm.org/D4252

tests: extract printrevset extension from test-glog-beautifygraph.t Differential Revision: https://phab.mercurial-scm.org/D4251

tests: add missing b'' prefix in test-check-code.t It now passes on Python 3. # skip-blame b prefix Differential Revision: https://phab.mercurial-scm.org/D4250

contrib: have check-code look at files in latin1 instead of ascii This way all files open. So far none of our patterns look like they'll care. Differential Revision: https://phab.mercurial-scm.org/D4249

tests: port inline extension in test for beautifygraph to Python 3 test-glog-beautifygraph.t now passes on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4247

beautifygraph: use slicing instead of subscripting on bytestr Differential Revision: https://phab.mercurial-scm.org/D4246

beautifygraph: use sysstr for checking encoding._wide # skip-blame just an r prefix Differential Revision: https://phab.mercurial-scm.org/D4245

stringutil: have buildrepr delegate to pprint for unknown types This stabilizes some revset reprs across Python 2 and 3. Differential Revision: https://phab.mercurial-scm.org/D4244

stringutil: teach pprint about sets This is the old (Python 2) way of printing sets. I actually prefer the Python 3 version of the repr, but this will result in less test churn in the short term. Differential Revision: https://phab.mercurial-scm.org/D4243

parser: replace bespoke _brepr with stringutil.pprint Differential Revision: https://phab.mercurial-scm.org/D4242

mq: use stringutil.pprint instead of pycompat.byterepr Resolves a few output changes on Python 3 in test-mq.t, and gets us two new passing tests. Differential Revision: https://phab.mercurial-scm.org/D4248

tests: remove expected output of test-parseindex2.py Everything uses unittest idioms now, so this can go away. Differential Revision: https://phab.mercurial-scm.org/D4185

parsers: adjust pure-python version to mimic a3dacabd476b This was caught by the tests, to my surprise. I'll also follow up with a test of the index[-1] behavior so we can be sure that remains consistent, as I think that currently has no coverage. Differential Revision: https://phab.mercurial-scm.org/D4183

tests: restore Python 3 compat in test-parseindex2.py I think this was previously getting lucky in Python 3, and would have stacktraced if something failed. Now that failure messages are eagerly computed, this turned into a problem. Differential Revision: https://phab.mercurial-scm.org/D4182

tests: port remaining bits of test-parseindex2 to unittest asserts Differential Revision: https://phab.mercurial-scm.org/D4181

tests: allow more detailed error message from re.compile test-grep.t now passes on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4240

grep: include format string in columns list This lets us correctly use %d as needed. Differential Revision: https://phab.mercurial-scm.org/D4239

grep: coerce username to bytestr, not str Differential Revision: https://phab.mercurial-scm.org/D4238

grep: difflib sequencematcher opcodes are native strs Differential Revision: https://phab.mercurial-scm.org/D4237

tests: allow for a bonus newline in base64'd email payload Python 3 adds this newline, which is harmless. test-patchbomb.t now passes on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4234

mail: be more cautious about bytes vs str for py3 compat It's suboptimal that we get a bytes on 2 and a unicode on 3, but it's easy to work with and I'm disinclined to change anything unless we start using some sort of type inferencer. Differential Revision: https://phab.mercurial-scm.org/D4233

patchbomb: use native strings when determining attachment disposition Differential Revision: https://phab.mercurial-scm.org/D4232

mail: always fall back to iso-8859-1 if us-ascii won't work (BC) It looks like this was a well-intentioned backwards compat hack for previewing the output of `hg email` in a stable way. Unfortunately I think this hack's time has come, because Python 3 does a much better job of ensuring it actually emits *valid* email messages. In particular, Python 2 would blindly trust us that the bytes we handed it were valid for the encoding we claimed, but Python 3 has some more sniff-tests that we end up failing. As a result, if we're going to print an email to the terminal, try us-ascii first, but if that fails go straight to iso-8859-1 which should be reasonably readable for ascii-compatible patch bodies. This *will* be a breaking change for ascii-incompatible textual patch content, but I don't think that's avoidable if we want to continue using the email library from the stdlib. .. bc:: Emails from the patchbomb extension will always be printed as though they are iso-8859-1 if they're not valid us-ascii. Previously, previewed emails were always claimed to be us-ascii and might contain invalid byte sequences. Differential Revision: https://phab.mercurial-scm.org/D4231

tests: put some Python 3 polish on inline Python invocations A couple of these became inline python sessions because they got more involved, and one of them is super-annoying and writes directly to sys.stdout.buffer because I just couldn't make it work any other way. Differential Revision: https://phab.mercurial-scm.org/D4230

patchbomb: don't unintentionally duplicate headers This dict-like of headers is only mostly dict-like: if you set a key that already exists, you it appends another value, rather than replacing the one that was already present. This fixes test-patchbomb-bookmark.t on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4229

patchbomb: use sysstrs when describing content-type Differential Revision: https://phab.mercurial-scm.org/D4228

patchbomb: use native strs for email header keys and values Differential Revision: https://phab.mercurial-scm.org/D4223

patchbomb: use email.encoders instead of email.Encoders No idea when this became a thing, but it exists for me in both 2.7 and 3.6. Differential Revision: https://phab.mercurial-scm.org/D4222

mail: properly handle email addresses typically being unicodes Visible progress in test-patchbomb.t on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4221

tests: fix Python3 issues in Python one-liners in test-patchbomb.t # skip-blame just byte prefixes Differential Revision: https://phab.mercurial-scm.org/D4220

dummysmtpd: accept additional kwargs from stdlib smtpd This was causing extremely mysterious failures because smtpd is implemented using asynchat, which in turn doesn't appear to do anything *remotely* helpful if an exception occurs. # no-check-commit because I'm editing a foo_bar function signature test-patchbomb-tls.t now passes in Python 3, but only because it doesn't check message bodies like test-patchbomb.t. test-patchbomb.t is *full* of doubled headers in the output (eg [0]) which seems like an odd failure mode. 0: @@ -141,12 +154,17 @@ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit + MIME-Version: 1.0 + Content-Type: text/plain; charset="us-ascii" + Content-Transfer-Encoding: 7bit Subject: [PATCH] bookmark X-Mercurial-Node: 8dab2639fd35f1e337ad866c372a5c44f1064e3c X-Mercurial-Series-Index: 1 X-Mercurial-Series-Total: 1 Differential Revision: https://phab.mercurial-scm.org/D4219

mail: fix debug print, which appears to have been broken for a long time I noticed this when trying to debug very mysterious dummysmtpd problems. It turns out you can set self.debuglevel to a number greater than 0 and have smtplib print helpful debug output, but this output on our side of things was broken. Differential Revision: https://phab.mercurial-scm.org/D4218

patchbomb: python 3 really wants those email addresses in unicode At this point, test-patchbomb-tls.t almost passes on Python 3, but I'm not really sure what the issue is: we just get a `abort: Connection unexpectedly closed` that doesn't make sense to me. Differential Revision: https://phab.mercurial-scm.org/D3957

mail: stop using the smtplib.SSLFakeFile and use socket.socket.makefile They're equivalent, and the latter is what Python 3.3 says to use in the release notes. Turns out it works on Python 2 as well. Differential Revision: https://phab.mercurial-scm.org/D3956

mail: modernize check for Python-with-TLS We used to be going indirectly through the socket module, but now we just check for the ssl module. Differential Revision: https://phab.mercurial-scm.org/D3955

mail: cope with Py3 unicode antics on email addresses Differential Revision: https://phab.mercurial-scm.org/D3954

mail: fix _encode to be more correct on Python 3 This code appears to be on the wrong side of the law in Python 2, at least some of the time. In Python 3, it's definitely wrong in places, but fortunately that's easy to fix. Differential Revision: https://phab.mercurial-scm.org/D3953

patchbomb: work around email module really wanting to write unicode data Differential Revision: https://phab.mercurial-scm.org/D3951

changegroup: invert conditional and dedent I don't like else-less blocks that are indented for no reason. Differential Revision: https://phab.mercurial-scm.org/D4217

changegroup: capture base node instead of rev in delta request I want the API in storage to be defined in terms of nodes, not revision numbers. Differential Revision: https://phab.mercurial-scm.org/D4216

changegroup: introduce requests to define delta generation Currently, we iterate through each revision we will be producing a delta for then call into 1 of 2 functions for generating that delta. Deltas are emitted as we iterate. A problem with this model is that revision generation is tightly coupled to the changegroup code. And the storage layer needs to expose APIs like deltaparent() so changegroup delta generation can produce a delta with that knowledge. Another problem is that in this model, deltas can only be produced sequentially after the previous delta was produced and emitted. Some storage backends might be capable of producing deltas in parallel (e.g. if the changegroup deltas are cached somewhere). This commit aims to solve these problems by turning delta generation into a 2 phase implementation where the first phase determines info about all the deltas that need to be generated and the 2nd phase resolves those deltas. We introduce a "revisiondeltarequest" object that holds data about a to-be-generated delta. We perform a full pass over all revisions whose delta is to be generated and generate a "revisiondeltarequest" for each. Then we iterate over the "revisiondeltarequest" instances and derive a "revisiondelta" for each. This patch was quite large. In order to avoid even more churn, aspects of the implementation are less than ideal. e.g. we're recording revision numbers instead of nodes in a few places and we don't yet have a formal API for resolving an iterable of revisiondeltarequest instances. Things will be improved in subsequent commits. Unfortunately, this commit reduces performance substantially. For `hg perfchangegroupchangelog` on my hg repo: ! wall 1.512607 comb 1.510000 user 1.490000 sys 0.020000 (best of 7) ! wall 2.150863 comb 2.150000 user 2.150000 sys 0.000000 (best of 5) And for `hg bundle -t none-v2 -a` for the mozilla-unified repo: 178.32user 4.22system 3:02.59elapsed 190.97user 4.17system 3:15.19elapsed Some of this was attributed to changelog slowdown. `hg perfchangegroupchangelog` on mozilla-unified: ! wall 21.688715 comb 21.690000 user 21.570000 sys 0.120000 (best of 3) ! wall 25.683659 comb 25.680000 user 25.540000 sys 0.140000 (best of 3) Profiling seems to reveal that the changelog slowdown is due to reading changelog revisions multiple times. First in the linknode callback to resolve the set of files changed. Second in the delta generation. Before, we likely had hit the last revision cache in the revlog when doing delta generation since we performed that immediately after performing the linknode callback. I'm not exactly sure where the other ~8s are being spent. It might be from overhead of constructing a few million revisiondeltarequest objects. I'm OK with the regression for now because it is in service of a larger cause (storage abstraction). I'll try to profile later and claw back the performance. Differential Revision: https://phab.mercurial-scm.org/D4215

changegroup: refactor delta parent code We had recently abstracted the delta parent functions to facilitate extracting code from cgpacker. Now that we're in a better place, it is time to revisit the design. Changegroup version 1 requires that the previous node be used as the delta parent. Later versions allow any available node to be used as the base. In the case where an arbitrary parent can be used, the choice of a delta parent is best left in the hands of the storage backend. So it makes sense for the delta parent selection to be hidden away in the storage layer. This means deferring the choice of the delta parent selection function to as close to delta generation time as possible. This commit moves the delta selection logic to essentially just before delta generation. However, because changegroup version 1 limits what we can do, we have retained the ability to force a delta against the previous revision. As part of this, I realized that the ellipsis parent function was unused! That's because ellipsis mode always sends full revisions and not deltas. Differential Revision: https://phab.mercurial-scm.org/D4214

changegroup: differentiate between fulltext and diff based deltas Previously, revisiondelta encoded a delta and an optional prefix containing a delta header. The underlying code could populate the delta with either a real delta or a fulltext revision. Following the theme of wanting to defer serialization of revision data to the changegroup format as long as possible, it seems prudent for the revision delta instance to capture what type of data is being represented. This could possibly allow us to encode revision data differently in the future. But for the short term, it makes the behavior of a revisiondelta more explicit. Differential Revision: https://phab.mercurial-scm.org/D4213

changegroup: minor cleanups to deltagroup() Differential Revision: https://phab.mercurial-scm.org/D4212

changegroup: emit revisiondelta instances from deltagroup() By abstracting the concept of a delta group away from its serialization (the changegroup format), we make it easier to establish alternate serialization formats. We also make it possible to move aspects of delta group generation into the storage layer. This will allow storage to make decisions about e.g. delta parent choices without the changegroup code needing storage APIs to determine delta parents. We're still a bit of a way from there. Future commits will work towards that world. Differential Revision: https://phab.mercurial-scm.org/D4211

changegroup: move file chunk emission to generate() Same deal as manifests. We want to get to a point where we can emit data structures from deltagroup() and derive the raw changegroup data as late as possible. Differential Revision: https://phab.mercurial-scm.org/D4210

changegroup: move manifest chunk emission to generate() We want to get to a point where we can emit data structures from deltagroup() and derive the raw changegroup data as late as possible. Differential Revision: https://phab.mercurial-scm.org/D4209

changegroup: move size tracking and end of manifests to generate() Preparing for all the generate* functions to emit data structures instead of raw chunks. Differential Revision: https://phab.mercurial-scm.org/D4208

changegroup: emit delta group close chunk outside of deltagroup() I want to make deltagroup() emit data structures rather than serialized deltas. Upcoming commits will demonstrate why. Differential Revision: https://phab.mercurial-scm.org/D4207

changegroup: extract cgpacker.group() to standalone function It doesn't need to be part of the packer class. Differential Revision: https://phab.mercurial-scm.org/D4206

changegroup: pass all state into group() This will allow us to split it into a standalone function. Differential Revision: https://phab.mercurial-scm.org/D4205