yuja added a comment.
> AFAIK, the protocol is never stateful (not sure how that'd work with http), so you can't rely on a notion of session-level state on the server to guarantee consistency. True. I think the new v2 protocol will eventually get around the issue since it will be more properly batched. @indygreg ? > I can see two plausible alternatives: > > 1. doing all the lookup queries and the bookmarks query in a single roundtrip. Is it guaranteed that a group of batchable queries will be sent in one go and won't be split up (if there are many of them for instance)? > 2. tweak the new lookup query to be instead `lookup(name, bookmark=node)`, which would mean: `lookup(name)` as if there exist a bookmark called `name` pointing to `node`. So kind of the snapshot idea, where you give the server the relevant part of the snapshot. 3. do lookup() again at the end of the transaction to detect race, and abort If the race doesn't occur frequently, I think it's okay to discard the pulled data. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5449 To: valentin.gatienbaron, #hg-reviewers Cc: yuja, indygreg, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
