[PATCH 1 of 2] changegroup: hide packermap behind methods

Martin von Zweigbergk martinvonz at google.com
Wed Jan 13 12:02:43 CST 2016


There was one little conflict in a test case that Greg changed recently.
I'll rebase this series and add the rewrites of the patches that introduce
an empty changegroup chunk separating manifests and files.

On Tue, Jan 12, 2016 at 11:22 PM Martin von Zweigbergk <
martinvonz at google.com> wrote:

> On Tue, Jan 12, 2016 at 10:27 PM Gregory Szorc <gregory.szorc at gmail.com>
> wrote:
>
>> On Tue, Jan 12, 2016 at 10:06 PM, Martin von Zweigbergk <
>> martinvonz at google.com> wrote:
>>
>>> # HG changeset patch
>>> # User Martin von Zweigbergk <martinvonz at google.com>
>>> # Date 1452661266 28800
>>> #      Tue Jan 12 21:01:06 2016 -0800
>>> # Node ID 3be4c174944f1e0e9e3b0d414a90a983d018ea9d
>>> # Parent  edd2615ad226c14f6904fc1738c3dc36431db223
>>> changegroup: hide packermap behind methods
>>>
>>
>> This series LGTM.
>>
>
> Thanks for a quick review! I depend on the changegroup patches getting in
> quickly for my internal work, so it is very much appreciated.
>
>
>> I only glanced at the test changes. I assume most of it is benign.
>>
>
> It's mostly because the "03" item disappears from the list of changegroup
> versions. The only exception is in test-treemanifest.t where we need to
> enable changegroup3 in a test case where experimental.treemanifest is
> explicitly turned off.
>
>
>> I approve of hiding cg3 behind an experimental flag until tree manifests
>> stabilize.
>>
>
> You'd better approve of it since you suggested it :-) Thanks!
>
>
>> The one downside of this is we lose exposing revision flags to
>> changegroups, which means no censor flags. I don't think anyone is using
>> that feature quite yet, so I don't think it will be missed.
>>
>
> Censor works with cg2 as well, it's just that it figures out whether a
> revision is censored by looking at the revision metadata (in the content)
> rather than the header.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160113/c02666a2/attachment.html>


More information about the Mercurial-devel mailing list