Mon, 05 Oct 2015 16:34:47 -0700 util.chunkbuffer: refactor chunk handling logic
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Oct 2015 16:34:47 -0700] rev 26479
util.chunkbuffer: refactor chunk handling logic This will make the next patch easier to read. It provides no benefit on its own.
Mon, 05 Oct 2015 16:28:12 -0700 util.chunkbuffer: special case reading everything
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Oct 2015 16:28:12 -0700] rev 26478
util.chunkbuffer: special case reading everything The new code results in simpler logic within the while loop. It is also faster since we avoid performing operations on the queue and buf collections. However, there shouldn't be any super hot loops for this since the whole point of chunkbuffer is to avoid reading large amounts of data at once. This does, however, make it easier to optimize chunkbuffer in a subsequent patch.
Mon, 05 Oct 2015 07:13:35 +0200 revert: add reference to backout
Mathias De Maré <mathias.demare@gmail.com> [Mon, 05 Oct 2015 07:13:35 +0200] rev 26477
revert: add reference to backout
Mon, 05 Oct 2015 07:11:48 +0200 backout: add reference to revert
Mathias De Maré <mathias.demare@gmail.com> [Mon, 05 Oct 2015 07:11:48 +0200] rev 26476
backout: add reference to revert
Fri, 25 Sep 2015 12:39:23 -0700 localrepo: allow wlock to be inherited
Siddharth Agarwal <sid0@fb.com> [Fri, 25 Sep 2015 12:39:23 -0700] rev 26475
localrepo: allow wlock to be inherited This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. When allowed, the parent process will pass down requisite information to the child process by way of this environment variable.
Sun, 04 Oct 2015 20:04:44 -0700 lock.release: don't call postrelease functions for inherited locks
Siddharth Agarwal <sid0@fb.com> [Sun, 04 Oct 2015 20:04:44 -0700] rev 26474
lock.release: don't call postrelease functions for inherited locks Review feedback from Pierre-Yves David. The postrelease functions typically assume the lock is not held at all.
Sun, 04 Oct 2015 20:02:50 -0700 lock: turn prepinherit/reacquire into a single context manager
Siddharth Agarwal <sid0@fb.com> [Sun, 04 Oct 2015 20:02:50 -0700] rev 26473
lock: turn prepinherit/reacquire into a single context manager Review feedback from Pierre-Yves David. This makes the overall code cleaner and less error-prone, and makes a previously explicitly checked error state impossible.
Sun, 04 Oct 2015 19:28:43 -0700 localrepo: add a note about parentenvvar
Siddharth Agarwal <sid0@fb.com> [Sun, 04 Oct 2015 19:28:43 -0700] rev 26472
localrepo: add a note about parentenvvar Review feedback from Pierre-Yves David.
Sun, 04 Oct 2015 12:11:44 -0700 exchange: add "streaming all changes" to bundle2 pulling
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 12:11:44 -0700] rev 26471
exchange: add "streaming all changes" to bundle2 pulling This is the beginning of client-side support for performing a stream clone using bundle2. The main bundle2 pull function checks whether to perform a streaming clone and outputs a message if so. While we have a duplicate message, it seems easier to have all the bundle2 console writing in one location and in an easy-to-read conditional block.
Sun, 04 Oct 2015 12:07:01 -0700 streamclone: move "streaming all changes" message location
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 12:07:01 -0700] rev 26470
streamclone: move "streaming all changes" message location Previously, the message was printed after we requested and started processing the remote stream. This seems like something that we should do before calling out to the remote. Moving it also makes it easier to deal with the bundle2 implementation.
Sun, 04 Oct 2015 19:06:06 -0700 streamclone: move payload header generation into own function
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 04 Oct 2015 19:06:06 -0700] rev 26469
streamclone: move payload header generation into own function The stream clone data over the wire protocol contains a header line indicating total file count and data size. In bundle2, this metadata can be captured by a part parameter and doesn't need to be in the body. In preparation for bundle2, have generatev1() return the raw metadata and move the header generation to its own function.
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.
(0) -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip