Thu, 15 Oct 2015 01:50:31 +0100 rebase: extra default destination in its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 01:50:31 +0100] rev 26717
rebase: extra default destination in its own function This makes it much simple to wrap for other extension.
Thu, 15 Oct 2015 01:47:28 +0100 revset: rename and test '_destmerge'
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 01:47:28 +0100] rev 26716
revset: rename and test '_destmerge' We make the name consistent with the one used by '_destupdate' and we ensure the code is run by testing it (abort is expected and merge would).
Thu, 15 Oct 2015 01:19:32 +0100 merge: directly get destination from destutil
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 01:19:32 +0100] rev 26715
merge: directly get destination from destutil There is no real value in using the revset over the function. The revset have no remaining users and will be taken care of in a later changesets.
Thu, 15 Oct 2015 01:11:00 +0100 destutil: move default merge destination into a function
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 01:11:00 +0100] rev 26714
destutil: move default merge destination into a function Function in destutil are much simpler to wrap and more flexible than revset. This also help consistency as 'destupdate' live here and cannot become a pure revset anyway.
Thu, 15 Oct 2015 01:35:44 +0100 revset: reintroduce and experimental revset for update destination
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 01:35:44 +0100] rev 26713
revset: reintroduce and experimental revset for update destination The revset is not ready for prime time yet. However it is useful to have some version of it exposed to help candidate users to play with it and provide feedback on what we should aim at. We add a small test to make sure the code runs.
Wed, 14 Oct 2015 15:11:53 -0400 changegroup: move manifest unpacking into its own method
Augie Fackler <augie@google.com> [Wed, 14 Oct 2015 15:11:53 -0400] rev 26712
changegroup: move manifest unpacking into its own method The upcoming cg3 will need different logic for unpacking manifests.
Thu, 01 Oct 2015 15:35:10 -0400 changegroup: move manifest packing into a separate function
Augie Fackler <augie@google.com> [Thu, 01 Oct 2015 15:35:10 -0400] rev 26711
changegroup: move manifest packing into a separate function A future change will introduce a new function on a cg3packer that can pack treemanifests as well as flatmanifests.
Wed, 30 Sep 2015 19:59:12 -0400 changegroup: rename manifest linknode closure for clarity
Augie Fackler <augie@google.com> [Wed, 30 Sep 2015 19:59:12 -0400] rev 26710
changegroup: rename manifest linknode closure for clarity Since I'm spending the time to understand this code, I may as well leave it clearer than I found it.
Tue, 29 Sep 2015 15:14:03 -0400 changegroup: reformat packermap and add comment
Augie Fackler <augie@google.com> [Tue, 29 Sep 2015 15:14:03 -0400] rev 26709
changegroup: reformat packermap and add comment I'm about to add a cg3, and it seems prudent to annotate what formats support what features. It strikes me that we may want to consider moving to a more feature-oriented model in the future, but we'll see how that looks in a little while I guess.
Wed, 14 Oct 2015 12:05:27 -0400 changegroup: document the public surface area of cg?unpackers
Augie Fackler <augie@google.com> [Wed, 14 Oct 2015 12:05:27 -0400] rev 26708
changegroup: document the public surface area of cg?unpackers This should help future readers at least a little.
Wed, 14 Oct 2015 11:58:56 -0400 changegroup: mark cg1unpacker.chunklength as private
Augie Fackler <augie@google.com> [Wed, 14 Oct 2015 11:58:56 -0400] rev 26707
changegroup: mark cg1unpacker.chunklength as private
Wed, 14 Oct 2015 11:58:35 -0400 changegroup: note why a few methods on cg1unpacker exist
Augie Fackler <augie@google.com> [Wed, 14 Oct 2015 11:58:35 -0400] rev 26706
changegroup: note why a few methods on cg1unpacker exist I'm not sure what to do abstraction-wise here. It might be more sensible to make a memoryrepo that could apply a bundle in-memory and then we could make the changegroup data be strictly an applyable stream, but that's an idea for Later.
Wed, 14 Oct 2015 11:32:33 -0400 revlog: rename bundle to cg to reflect its nature as a cg?unpacker
Augie Fackler <augie@google.com> [Wed, 14 Oct 2015 11:32:33 -0400] rev 26705
revlog: rename bundle to cg to reflect its nature as a cg?unpacker The new convention is that bundles contain changegroups. bundle1 happens to *only* be a changegroup, but bundle2 is a more featureful container that isn't something you can pass to addgroup().
Tue, 13 Oct 2015 17:16:10 -0400 changegroup: mark _addchangegroupfiles as module-private
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:16:10 -0400] rev 26704
changegroup: mark _addchangegroupfiles as module-private I'm trying to reason about the public surface area of this module now, so it's worth tagging private things as such.
Tue, 13 Oct 2015 17:14:37 -0400 changegroup: delete now-unused addchangegroup method
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:14:37 -0400] rev 26703
changegroup: delete now-unused addchangegroup method
Tue, 13 Oct 2015 17:14:07 -0400 localrepo: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:14:07 -0400] rev 26702
localrepo: use cg?unpacker.apply() instead of changegroup.addchangegroup() This is in localpeer, so it lives. Had it been in localrepo instead, I would have tried to exterminate it.
Tue, 13 Oct 2015 17:12:46 -0400 repair: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:12:46 -0400] rev 26701
repair: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Tue, 13 Oct 2015 17:12:29 -0400 exchange: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:12:29 -0400] rev 26700
exchange: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Tue, 13 Oct 2015 17:12:12 -0400 commands: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:12:12 -0400] rev 26699
commands: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Tue, 13 Oct 2015 17:11:52 -0400 bundle2: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:11:52 -0400] rev 26698
bundle2: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Tue, 13 Oct 2015 17:11:18 -0400 shelve: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:11:18 -0400] rev 26697
shelve: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Tue, 13 Oct 2015 17:14:21 -0400 histedit: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 17:14:21 -0400] rev 26696
histedit: use cg?unpacker.apply() instead of changegroup.addchangegroup()
Tue, 13 Oct 2015 16:58:51 -0400 changegroup: migrate addchangegroup() to forward to cg?unpacker.apply()
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 16:58:51 -0400] rev 26695
changegroup: migrate addchangegroup() to forward to cg?unpacker.apply() I'll clean up callers in subsequent patches, then remove the forwarding.
Tue, 13 Oct 2015 15:54:05 -0400 changegroup: move source check to top of addchangegroup
Augie Fackler <augie@google.com> [Tue, 13 Oct 2015 15:54:05 -0400] rev 26694
changegroup: move source check to top of addchangegroup This is preparation for some refactoring.
Thu, 15 Oct 2015 09:52:32 -0400 error: remove superfluous pass statements
Augie Fackler <augie@google.com> [Thu, 15 Oct 2015 09:52:32 -0400] rev 26693
error: remove superfluous pass statements
Mon, 12 Oct 2015 18:49:23 -0700 hook: raise a separate exception for when loading a hook fails
Siddharth Agarwal <sid0@fb.com> [Mon, 12 Oct 2015 18:49:23 -0700] rev 26692
hook: raise a separate exception for when loading a hook fails For easier catching.
Wed, 14 Oct 2015 11:05:53 -0700 clonebundles: advertise clone bundles feature to clients
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 11:05:53 -0700] rev 26691
clonebundles: advertise clone bundles feature to clients Server operators that have enabled clone bundles probably want clients to use it. This patch introduces a feature that will insert a bundle2 "output" part that advertises the existence of the clone bundles feature to clients that aren't using it. The server uses the "cbattempted" argument to "getbundle" to determine whether a client supports clone bundles and to avoid sending the message to clients that failed the clone bundle for whatever reason.
Wed, 14 Oct 2015 10:36:20 -0700 exchange: advertise if a clone bundle was attempted
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 10:36:20 -0700] rev 26690
exchange: advertise if a clone bundle was attempted The client now sends a "cbattempted" boolean flag to the "getbundle" wire protocol command to tell the server whether a clone bundle was attempted. The presence of this flag will enable the server to conditionally emit a bundle2 "output" part advertising the availability of clone bundles to compatible clients that don't have it enabled.
Tue, 13 Oct 2015 14:55:02 -0700 exchange: record that we attempted to fetch a clone bundle
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 14:55:02 -0700] rev 26689
exchange: record that we attempted to fetch a clone bundle This is needed so a subsequent patch can conditionally add a bundle2 part to the "getbundle" wire protocol command depending on whether a clone bundle was attempted.
Tue, 13 Oct 2015 12:41:32 -0700 exchange: provide hint on how to disable clone bundles
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 12:41:32 -0700] rev 26688
exchange: provide hint on how to disable clone bundles If a clone bundle persistently fails to apply, users need a way to disable it so they have a hope of the clone working. Change the hint for the abort scenario to advertise the config option to disable clone bundles.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip