This is an archive of the discontinued Mercurial Phabricator instance.

setdiscovery: don't call "heads" wire command when heads specified
ClosedPublic

Authored by martinvonz on Feb 1 2018, 2:52 PM.

Details

Summary

Our custom server has too many heads to announce (one per code review,
plus a public head), but it still lets the user request one of them by
doing

hg pull -r <some expression>

After the client has resolved the expression to a set of nodeids by
calling the "lookup" wire command, it will start the discovery
phase. Before this patch, that doesn't take the requested heads into
account and unconditionally calls the server's "heads" command to find
all its heads. One consequence of that the "all remote heads known
locally" case triggers if the client already had the public head and
the user will see a "no changes found" message that's unrelated to the
head they requested. That message confused me for a while. More
imporantly, it also means that pullop.cgresult incorrectly (given our
arguably misbehaving server) gets set to 0 (no changesets added),
which confused some of our extensions.

This patch makes it so the client skips the "heads" command if the
user requested specific revisions.

Since the "heads" command is normally batched with the first "known"
command and calculating the list of heads is probably cheap, I don't
expect much improvement in speed from this.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

martinvonz created this revision.Feb 1 2018, 2:52 PM
indygreg accepted this revision.Feb 1 2018, 3:48 PM
indygreg added a subscriber: indygreg.

I initially thought this would have test fallout. But since we're using a batch command to issue the heads wire protocol command, it won't show up in HTTP logs. We'd only catch it in verbose/debug logging, which we don't do a lot of. So no test fallout is expected.

FWIW, while computing DAG heads is probably cheap, sending them over the wire may not be. 41 bytes per head can add up pretty quickly and turn what would be a <1kb response into several kb.

This revision is now accepted and ready to land.Feb 1 2018, 3:48 PM
This revision was automatically updated to reflect the committed changes.