martinvonz added inline comments. INLINE COMMENTS
> pulkit wrote in narrowbundle2.py:54 > I do plan to support ellipses with the wireprotocol command. Since ellipses > case will require sending a bundle not a changegroup, I plan to make that as > a seperate function and call the required functions depending on ellipses is > enabled or not. > > Yeah the "known" set is needed. I also forgot to include that in wireprotocol > command. Thanks! > Since ellipses case will require sending a bundle not a changegroup I'm not sure it will require that. The point of the "known" set was initially just to make sure that the server included all nodes that the client may have local commits based off of (see [1] and [2]). But then we realized that it would make more sense for widening and narrowing not to add or remove any ellipsis nodes. When interacting with our Google-internal server, that's how it actually works. I don't think I got around to making the core server completely trust the "known" set (or just the "common" set when not using ellipses), but I still think that's the right direction. Maybe we should still wrap the returned changegroup in a bundle so we have more flexibility? It may be useful at least for letting the server include messages for the client. It's hard to say what else we may want to include in the bundle later. [1] https://bitbucket.org/Google/narrowhg/commits/8c6dba960138b2758d6a37147d8338f751a7a05c [2] https://bitbucket.org/Google/narrowhg/commits/ba65a969df547df0ccf26901bb3c5bd4e21445f2 REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D4786 To: pulkit, durin42, #hg-reviewers Cc: martinvonz, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
