Mon, 05 Oct 2015 23:17:01 -0700 export: introduce a generic way to add patch header on export
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 23:17:01 -0700] rev 26545
export: introduce a generic way to add patch header on export Extensions currently have no easy way to add data to exported patch. This is now fixed using a generic mechanism in the same fashion used by bundle2. Tests are coming in the next changeset with its first user.
Mon, 05 Oct 2015 00:23:20 -0700 incoming: request a bundle2 when possible (BC)
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:23:20 -0700] rev 26544
incoming: request a bundle2 when possible (BC) Incoming was using bundle1 in all cases, as bundle1 is restricted to changegroup1 and does not support general delta, this can lead to significant CPU overhead if the server is using general delta storage. We now properly request and store a bundle2 to disk. If the server include any output or error in the bundle, they will be stored on disk and replayed when the bundle is read. As 'hg incoming' is going to read the bundle right away, we call that 'good' enough and go back to the bigger plan of having general delta on by default. This was tracked as 4864
Mon, 05 Oct 2015 00:18:11 -0700 bundlerepo: indent some code to prepare next patch
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:18:11 -0700] rev 26543
bundlerepo: indent some code to prepare next patch We are about to add a new condition. Code is indented in a separated patch for readability.
Thu, 08 Oct 2015 01:40:21 -0700 bundle2: add a way to just forward the bundle2 stream to another user
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Oct 2015 01:40:21 -0700] rev 26542
bundle2: add a way to just forward the bundle2 stream to another user There is use case for directly forward and bundle2 stream from the peer to a file (eg: 'hg incoming --bundle'), However ssh peers have no way to know the 'getbundle' is over except for actually interpreting the bundle. So we need to have the unbundle do the interpreting and forward job. The function is marked as private to highlight that this is terrible and that we are sorry.
Mon, 05 Oct 2015 01:10:49 -0700 bundle2: split parameter retrieval and processing
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 01:10:49 -0700] rev 26541
bundle2: split parameter retrieval and processing We want to introduce a simple way to forward the content of a bundle2 stream. For this purpose, we will need to both yield the parameters block and process it (to apply any behavior change it might indicate).
Mon, 05 Oct 2015 00:14:47 -0700 changegroup: extract the file management part in its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:14:47 -0700] rev 26540
changegroup: extract the file management part in its own function The current writebundle function do two things: - taking a changegroup-packer instance and storing it into a valid bundle with proper header. - creating a temporary or requested file to store that bundle We would like to make it easier to forward bundle stream directly from a remote peer to a file, so we split the two logic to be able to skip the one about building a valid bundle (the remote is already sending one).
Sun, 04 Oct 2015 21:48:19 -0700 unbundle: properly read head modification result from bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 04 Oct 2015 21:48:19 -0700] rev 26539
unbundle: properly read head modification result from bundle2 We were reading the wrong key...
Wed, 07 Oct 2015 23:04:31 +0900 revset: strip off "literal:" prefix from bookmark not found error
Yuya Nishihara <yuya@tcha.org> [Wed, 07 Oct 2015 23:04:31 +0900] rev 26538
revset: strip off "literal:" prefix from bookmark not found error This is what branch() and tag() do.
Wed, 07 Oct 2015 23:00:29 +0900 revset: do not fall through to revspec for literal: branch (issue4838)
Yuya Nishihara <yuya@tcha.org> [Wed, 07 Oct 2015 23:00:29 +0900] rev 26537
revset: do not fall through to revspec for literal: branch (issue4838) If "literal:" is specified, it must not be a revset expression. It should error out with a better message.
Wed, 07 Oct 2015 21:08:14 +0100 hgweb: ensure both foreground and background colors are specified (issue4872)
Gijs Kruitbosch <gijskruitbosch@gmail.com> [Wed, 07 Oct 2015 21:08:14 +0100] rev 26536
hgweb: ensure both foreground and background colors are specified (issue4872) When users configure the default foreground or background color to non-default (black on white) values, several hgweb styles lack contrast for headers and table row items. This patch fixes that by ensuring that where either foreground or background colors are specified, both are specified.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip