This is an archive of the discontinued Mercurial Phabricator instance.

Differential D4436

httppeer: expose capabilities for each command
ClosedPublic

Authored by indygreg on Aug 31 2018, 6:57 PM.

Details

Reviewers
None
Group Reviewers
hg-reviewers
Commits
rHGa5de21c9e370: httppeer: expose capabilities for each command
Summary

This will help code using peers to sniff out exactly what servers
support.

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

indygreg created this revision.Aug 31 2018, 6:57 PM
indygreg updated this revision to Diff 10761.Sep 4 2018, 2:28 PM
durin42 added a subscriber: durin42.Sep 12 2018, 10:39 AM

Hm, I worry this isn't explicit enough. Do you have a specific reason for why this is a thing we should do?

indygreg added a comment.Sep 12 2018, 12:55 PM
In D4436#69390, @durin42 wrote:

Hm, I worry this isn't explicit enough. Do you have a specific reason for why this is a thing we should do?

Honestly, I did this to make the subsequent patches easier. The way I'm going with the partial clone work, it is likely we'll need the peer to consult the capabilities data structure directly instead of trying to map everything to a string lookup (which is what capable(name) is doing). Specifically, for things like changesetdata, we'll likely start exposing the available data fields in the capabilities dict and clients will want a way to check if a specific field is available.

So there's a good chance capable(name) isn't long for this world. At least not on version 2 peers. Things are still evolving.

indygreg updated this revision to Diff 10960.Sep 12 2018, 1:11 PM
durin42 added a comment.Sep 12 2018, 5:41 PM

Hmm. I'm still uneasy about this. Maybe we could make it a dev-mode thing and not be something we depend on long term?

indygreg added a comment.Sep 14 2018, 6:17 PM
In D4436#69564, @durin42 wrote:

Hmm. I'm still uneasy about this. Maybe we could make it a dev-mode thing and not be something we depend on long term?

I think an outcome of our VC yesterday was you were OK with this. IIRC you thought this was a server-side thing. When in fact this code runs on the client and is inventing e.g. command-changeset capabilities so code can check for the existence of a command via an artificial capability. In the future, v2 peers will likely expose the raw capabilities dict and we'll do something more intelligent for sniffing features.

Closed by commit rHGa5de21c9e370: httppeer: expose capabilities for each command (authored by indygreg). · Explain WhySep 14 2018, 11:15 PM
This revision was automatically updated to reflect the committed changes.

Revision Contents
Changeset List

PathPackages
Mmercurial/httppeer.py (4 lines)

Diff 11057

mercurial/httppeer.py

# Maps to commands that are available. # Maps to commands that are available.
if name in ('branchmap', 'getbundle', 'known', 'lookup', 'pushkey'): if name in ('branchmap', 'getbundle', 'known', 'lookup', 'pushkey'):
return True return True
# Other concepts. # Other concepts.
if name in ('bundle2',): if name in ('bundle2',):
return True return True
# Alias command-* to presence of command of that name.
if name.startswith('command-'):
return name[len('command-'):] in self._descriptor['commands']
return False return False
def requirecap(self, name, purpose): def requirecap(self, name, purpose):
if self.capable(name): if self.capable(name):
return return
raise error.CapabilityError( raise error.CapabilityError(
_('cannot %s; client or remote repository does not support the %r ' _('cannot %s; client or remote repository does not support the %r '