Sat, 12 Apr 2014 14:56:55 -0400 bundle2: lazily generate the changegroup part in exchange.getbundle
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 12 Apr 2014 14:56:55 -0400] rev 21002
bundle2: lazily generate the changegroup part in exchange.getbundle Now that we have lazy generation of parts, let's use it.
Fri, 11 Apr 2014 08:04:16 -0700 bundle2: support chunk iterator as part data
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 11 Apr 2014 08:04:16 -0700] rev 21001
bundle2: support chunk iterator as part data When the `part.data` attribute is an iterator, we assume it is an iterator of chunks and use it. We use a chunkbuffer to yield chunks of 4096 bytes. The tests are updated to use this feature.
Thu, 10 Apr 2014 12:33:20 -0700 bundle2: extract a _payloadchunks method for part
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 10 Apr 2014 12:33:20 -0700] rev 21000
bundle2: extract a _payloadchunks method for part We are preparing streaming capability for part. So the generation of payload chunk will becomes more complex. We extract this part in its own function before any changes.
Thu, 10 Apr 2014 13:19:00 -0700 changegroup: move chunk extraction into a getchunks method of unbundle10
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 10 Apr 2014 13:19:00 -0700] rev 20999
changegroup: move chunk extraction into a getchunks method of unbundle10 This code used to be in `writebundle` only. We needs to make it more broadly available for bundle2. The "changegroup" bundle2 part has to retrieve the binary content of changegroup stream. We moved the chunks retrieving code into the `unbundle10` object directly and the `writebundle` code is now using that. This split is useful for bundle2 purpose, we want to be able to easily stream changegroup content in a part. To keep thing simples, we kept compression out of the new methods. If it make more sense in the future, compression may get included in this function too.
Tue, 25 Mar 2014 15:05:11 -0700 bundle2: use reply part to return result of addchangegroup
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Mar 2014 15:05:11 -0700] rev 20998
bundle2: use reply part to return result of addchangegroup We now have an official way to return the result of addchangegroup. The tests are updated to check that the return bundle is properly created. It will be used when push is bundle2 enabled.
Fri, 04 Apr 2014 14:24:11 -0700 bundle2: produce a bundle2 reply
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Apr 2014 14:24:11 -0700] rev 20997
bundle2: produce a bundle2 reply We do not know yet what kind of data future features and extensions will need to exchange. To handle that, bundle2 allows to send arbitrary content to the server. As a consequence, we need to be able to reply arbitrary content to the client. And, we can use bundle2 to transmit those arbitrary data. When a client will push a bundle2 to the server, the server will reply with a bundle2 itself. This changeset installs the first stone of this logic and test it.
Fri, 11 Apr 2014 08:24:59 -0700 bundle2: add reply awareness to unbundlerecords
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 11 Apr 2014 08:24:59 -0700] rev 20996
bundle2: add reply awareness to unbundlerecords We need an efficient way to handle bundle replies. The unbundle records class is extended to carry such data.
Tue, 01 Apr 2014 00:07:17 -0700 bundle2: add an integer id to part
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 01 Apr 2014 00:07:17 -0700] rev 20995
bundle2: add an integer id to part For sending response to a pushed bundle, we need to link reply parts to request part. We introduce a part id for this purpose. This is a 32 bit unique integer stored in the header.
Mon, 07 Apr 2014 23:10:20 +0200 largefiles: don't prompt when one side of merge was changed but didn't change
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:10:20 +0200] rev 20994
largefiles: don't prompt when one side of merge was changed but didn't change This can happen after backout or grafts or criss cross merges. We already do the same (but slightly different) thing in manifestmerge and filemerge.
Mon, 07 Apr 2014 15:37:27 -0500 color: fallback and test label as an effect
Sean Farley <sean.michael.farley@gmail.com> [Mon, 07 Apr 2014 15:37:27 -0500] rev 20993
color: fallback and test label as an effect With this changeset, we can now send a color name directly to the label function, e.g. $ hg log -r . -T "{label('red', node|short)}\n"
Mon, 07 Apr 2014 15:33:46 -0500 color: extract method for determining a valid effect
Sean Farley <sean.michael.farley@gmail.com> [Mon, 07 Apr 2014 15:33:46 -0500] rev 20992
color: extract method for determining a valid effect This patch is just setup work so that we can reduce code duplication and have one place to define a valid effect.
Mon, 07 Apr 2014 23:17:51 +0200 revlog: use context ancestor instead of changelog ancestor
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:17:51 +0200] rev 20991
revlog: use context ancestor instead of changelog ancestor We want to move in this direction.
Tue, 25 Feb 2014 20:31:53 +0100 copies: guard debug section with ui.debugflag
Mads Kiilerich <madski@unity3d.com> [Tue, 25 Feb 2014 20:31:53 +0100] rev 20990
copies: guard debug section with ui.debugflag
Tue, 25 Feb 2014 20:31:51 +0100 copies: remove _checkcopies wrapper - it does no good
Mads Kiilerich <madski@unity3d.com> [Tue, 25 Feb 2014 20:31:51 +0100] rev 20989
copies: remove _checkcopies wrapper - it does no good mergecopies might be doomed but it is not dead yet ...
Mon, 07 Apr 2014 23:17:51 +0200 transplant: use context ancestor instead of changelog ancestor
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:17:51 +0200] rev 20988
transplant: use context ancestor instead of changelog ancestor We want to move in this direction. ctx.ancestor is in a better position for handling a situation with multiple ancestors.
Mon, 07 Apr 2014 23:17:51 +0200 commit: use revlog.commonancestors instead of .ancestor
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:17:51 +0200] rev 20987
commit: use revlog.commonancestors instead of .ancestor This do probably not make any real difference but is slightly more correct and we would like to get rid of flog.ancestor.
(0) -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 +30000 tip