Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 18:44:46 -0700] rev 26468
streamclone: move payload header line consumption
bundle2 parts have parameters. These are a logical place for "header"
data such as the file count and payload size of stream clone data. In
preparation for supporting stream clones with bundle2, move the
consumption of the header line from the payload into
maybeperformlegacystreamclone().
Note: the header line is still being emitted by generatev1(). This will
be addressed in a subsequent patch.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 18:35:19 -0700] rev 26467
streamclone: teach canperformstreamclone to be bundle2 aware
We add an argument to canperformstreamclone() to return False if a
bundle2 stream clone is available. This will enable the legacy stream
clone step to no-op when a bundle2 stream clone is supported.
The commented code will be made active when bundle2 supports streaming
clone.
This patch does foreshadow the introduction of the "stream" bundle2
capability and its "v1" sub-capability. The bundle2 capability mirrors
the existing "stream" capability and is needed so clients know whether a
server explicitly supports streaming clones over bundle2 (servers up to
this point support bundle2 without streaming clone support).
The sub-capability will denote which data formats and variations are
supported. Currently, the value "v1" denotes the existing streaming
clone data format, which I intend to reuse inside a bundle2 part. My
intent is to eventually introduce alternate data formats that can be
produced and consumed more efficiently. Having a sub-capability means
we don't need to introduce a new top-level bundle2 capability when new
formats are introduced. This doesn't really have any implications
beyond making the capabilities namespace more organized.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 11:50:42 -0700] rev 26466
streamclone: refactor canperformstreamclone to accept a pullop
This isn't strictly necessary. But a lot of pull functionality accepts a
pulloperation so extra state can be added easily. It also enables
extensions to perform more powerful things.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 12:03:30 -0700] rev 26465
exchange: expose bundle2 availability on pulloperation
Like the previous patch, the value is cached and will prevent a function
level import in streamclone.py.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 18:31:53 -0700] rev 26464
exchange: expose bundle2 capabilities on pulloperation
This adds a cache and makes accessing the capabilities slightly simpler,
as you don't need to directly go through the bundle2 module. This will
also help prevent a function-level import in streamclone.py.
This patch arguably isn't necessary. But I think it makes things
slightly nicer.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 04 Oct 2015 21:33:29 +0900] rev 26463
keyword: make restrict mode False while updating files for rollback
This is a preparation for using 'repo.rollback()' instead of aborting
a current running transaction for "shelve" and "unshelve".
Before this patch, updating files as a part of 'repo.rollback()'
overridden by keyword extension always follows 'restrict' mode of the
command currently executed.
"merge", "unshelve" and so on should be 'restrict'-ed, because keyword
expansion may cause unexpected conflicts at merging while these
commands.
But, if 'repo.rollback()' is invoked while executing 'restrict'-ed
commands, modified files in the working directory are marked as
"CLEAN" unexpectedly by code path below:
# 'lookup' below is True at updating modified files for rollback
kwcmd = self.restrict and lookup # kwexpand/kwshrink
:
if kwcmd:
self.repo.dirstate.normal(f)
On the other hand, "rollback" command isn't 'restrict'-ed, because
rollbacking itself doesn't imply merging.
Therefore, disabling 'restrict' mode while updating files as a part of
'repo.rollback()' regardless of current 'restrict' mode should be
reasonable.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 11:34:28 -0700] rev 26462
streamclone: rename and document maybeperformstreamclone()
Upcoming patches will introduce bundle2 based streaming clones. Add
"legacy" to the function name and add a docstring clarifying the intent of
the function.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 11:27:10 -0700] rev 26461
streamclone: move applyremotedata() into maybeperformstreamclone()
Future work around stream cloning will be implemented in a bundle2
world. This code will only be used in the legacy code path and
doesn't need to be abstracted or extensible.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Oct 2015 09:53:56 -0700] rev 26460
branchmap: move branch cache code out of streamclone.py
This is low-level branch map and cache manipulation code. It deserves to
live next to similar code in branchmap.py. Moving it also paves the road
for multiple consumers, such as a bundle2 part handler that receives
branch mappings from a remote.
This is largely a mechanical move, with only variable names and
indentation being changed.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 02 Oct 2015 23:08:15 -0700] rev 26459
streamclone: move streamin() into maybeperformstreamclone()
streamin() only had a single consumer. And it always only ever will
because it is strongly coupled with the current,
soon-to-be-superseded-by-bundle2 functionality.
The return value has been dropped because nobody was using it.