This is an archive of the discontinued Mercurial Phabricator instance.

narrow: add narrow and ellipses as server capabilities
ClosedPublic

Authored by pulkit on Sep 10 2018, 11:13 AM.

Details

Summary

Right now we don't have a way to differentiate between whether a server can
serve ellipsis or not. The way we check whether a server is narrow enabled is by
checking bundle2 capability which does not scale outside of bundle2 world.

The goal is to use have wireprotocol commands just like remotefilelog for
widening the narrow clone, atleast in non-ellipses cases. Having a server
capability will help there as we can't rely on bundle2 capability there.

Also having a server capability is neat than having a bundle2 capability.

There are lot of things we can optimize locally on the client side by knowing
before hand that whether the server supports ellipses or not.

This will also help us in making sure that a client ellipses repo does not
communicate with a server repo without ellipses.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

pulkit created this revision.Sep 10 2018, 11:13 AM

checking bundle2 capability which does not scale outside of bundle2 world.

Is your goal to use narrowness without ellipsis nodes with a changegroup1 server? Can we split this patch up so it just splits up the "narrow" capability into "narrow" and "ellipsis" and then we can consider cg1 support in a separate patch?

hgext/narrow/narrowbundle2.py
35

I'd rather not include "narrow" in the name. It doesn't necessarily require narrowness. You can imagine using ellipsis nodes to achieve a shallow clone that still has all paths.

martinvonz requested changes to this revision.Sep 10 2018, 1:48 PM
This revision now requires changes to proceed.Sep 10 2018, 1:48 PM

checking bundle2 capability which does not scale outside of bundle2 world.

Is your goal to use narrowness without ellipsis nodes with a changegroup1 server? Can we split this patch up so it just splits up the "narrow" capability into "narrow" and "ellipsis" and then we can consider cg1 support in a separate patch?

No, that's not a goal. The goal is to make a wireprotocol command and prevent using pull to exchange data atleast for non-ellipsis cases.

In D4521#69012, @pulkit wrote:

checking bundle2 capability which does not scale outside of bundle2 world.

Is your goal to use narrowness without ellipsis nodes with a changegroup1 server? Can we split this patch up so it just splits up the "narrow" capability into "narrow" and "ellipsis" and then we can consider cg1 support in a separate patch?

No, that's not a goal. The goal is to make a wireprotocol command and prevent using pull to exchange data atleast for non-ellipsis cases.

Ah, that makes sense. I don't know why we made it a bundle2 capability. Could you update the commit message to clarify that the point is that we want the capability to apply to other commands?

Also note that I left a question for you about NELLIPSESCAP.

pulkit edited the summary of this revision. (Show Details)Sep 11 2018, 5:56 AM
pulkit updated this revision to Diff 10875.
martinvonz accepted this revision.Sep 11 2018, 11:47 AM
martinvonz added inline comments.
hgext/narrow/narrowbundle2.py
51

Should this perhaps be ELLIPSISCAP? I don't think the bundle is currently affected by the narrowness. OTOH, perhaps there should be some "narrowspec" part in the bundle to indicate which paths it contains? Either way, that can be changed in a later patch (if at all).

This revision is now accepted and ready to land.Sep 11 2018, 11:47 AM
This revision was automatically updated to reflect the committed changes.