Tue, 06 Oct 2015 02:04:06 -0700 extract: simplify parents assignement
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:04:06 -0700] rev 26548
extract: simplify parents assignement We move to the more standard style of: value = default if special: value = other This is more consistent and compact.
Tue, 06 Oct 2015 02:01:53 -0700 patch: move 'extract' return to a dictionnary
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:01:53 -0700] rev 26547
patch: move 'extract' return to a dictionnary The final goal here is to be able to parse, return and process arbitrary data from patch. This mirror the recently added ability to add arbitrary data to patch headers. The first step is to return something more flexible, so we return a dict without changing any other logic.
Tue, 06 Oct 2015 01:49:04 -0700 patchbomb: add experimental config of a "pullurl" and export it
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 01:49:04 -0700] rev 26546
patchbomb: add experimental config of a "pullurl" and export it This config allows to specify a public location where your changeset can be found. It then include a dedicated patch header show a command to be used to retrieve the change. See the test for example. This is flagged as experimental because this feature is not safe until we have more logic to test that: - changeset actually exists on destination - changeset is draft on destination. As all this is experimental, bike shedding can happily happens before we remove the experimental flag.
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip