Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 10:03:26 -0700] rev 26687
exchange: document filterclonebundleentries
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.
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.
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.
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.
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.