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.
Wed, 14 Oct 2015 10:03:26 -0700 exchange: document filterclonebundleentries
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 10:03:26 -0700] rev 26687
exchange: document filterclonebundleentries
Wed, 14 Oct 2015 10:58:35 -0700 wireproto: properly parse false boolean args (BC)
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 10:58:35 -0700] rev 26686
wireproto: properly parse false boolean args (BC) The client represents boolean arguments as '0' and '1'. bool('0') == bool('1') == True, so a simple bool(val) isn't sufficient for converting the argument back to a bool type. Currently, "obsmarkers" is the only boolean argument to getbundle. I /think/ the only place where we currently set the "obsmarkers" argument is during bundle2 pulls. As a result of this bug, the server /might/ be sending obsolete markers bundle2 part(s) to clients that don't request them. That is why I marked this BC. Surprisingly there was no test fall out from this change. I suspect a lapse in test coverage.
Thu, 15 Oct 2015 03:29:00 +0100 bundle2: gracefully skip 'obsmarkers' part if evolution is disabled
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 03:29:00 +0100] rev 26685
bundle2: gracefully skip 'obsmarkers' part if evolution is disabled We would skip the part if it was fully unknown, so we should also skip it if we know we won't be able to apply it. This will allow us to produce bundles with obsolescence markers alongside changegroup while still being able to apply them on any client.
Thu, 15 Oct 2015 12:45:34 +0100 obsstore: make the readonly attribute accessible
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 12:45:34 +0100] rev 26684
obsstore: make the readonly attribute accessible We want to gracefully handle the read only case in some case (current target: advisory obsmarkers parts in bundle2). So we expose the attribute in a clean way.
Mon, 05 Oct 2015 04:26:26 -0700 update: introduce a 'UpdateAbort' exception
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 04:26:26 -0700] rev 26683
update: introduce a 'UpdateAbort' exception The 'postincoming' function used by 'hg pull --update' and 'hg unbundle' is catching 'Abort' exceptions to intercept failed update. This feel a bit too wide to me, so I'm introducing a more precise exception to specify update destination issues.
Mon, 05 Oct 2015 21:42:09 -0700 update: "deprecate" call to 'merge.update' without a destination
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 21:42:09 -0700] rev 26682
update: "deprecate" call to 'merge.update' without a destination Now that all internal callers pre-compute and set a destination at a higher level it feels like we can kill this API. This will allow us to simplify this function. However I feel like this is a bit too central and critical to break now. I'm adding a devel warning to let extension make catch this in the next cycle.
Wed, 14 Oct 2015 20:35:06 -0700 shelve: delete shelve statefile on any exception during abort
Christian Delahousse <cdelahousse@fb.com> [Wed, 14 Oct 2015 20:35:06 -0700] rev 26681
shelve: delete shelve statefile on any exception during abort When a user's repository is in an unfinished unshelve state and they choose to abort, at a minimum, the repo should be out of that state. We've found situations where the user could not leave the state unless manually deleting the state file. This fix ensures that no matter what exception may be raised during the abort, the shelved state file will be deleted, the user will be out of the unshelve state and they can get their repository into a workable condition.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip