Sun, 04 Oct 2015 18:44:46 -0700 streamclone: move payload header line consumption
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.
Sun, 04 Oct 2015 18:35:19 -0700 streamclone: teach canperformstreamclone to be bundle2 aware
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.
Sun, 04 Oct 2015 11:50:42 -0700 streamclone: refactor canperformstreamclone to accept a pullop
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.
Sun, 04 Oct 2015 12:03:30 -0700 exchange: expose bundle2 availability on pulloperation
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.
Sun, 04 Oct 2015 18:31:53 -0700 exchange: expose bundle2 capabilities on pulloperation
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.
Sun, 04 Oct 2015 21:33:29 +0900 keyword: make restrict mode False while updating files for rollback
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.
Sun, 04 Oct 2015 11:34:28 -0700 streamclone: rename and document maybeperformstreamclone()
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.
Sun, 04 Oct 2015 11:27:10 -0700 streamclone: move applyremotedata() into maybeperformstreamclone()
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.
Sat, 03 Oct 2015 09:53:56 -0700 branchmap: move branch cache code out of streamclone.py
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.
Fri, 02 Oct 2015 23:08:15 -0700 streamclone: move streamin() into maybeperformstreamclone()
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip