changeset 25369:02defdb1b628

pull: only prefetch bookmarks when using bundle1

All bundle2 servers now support the 'listkeys' part(1), so we'll
always be able to fetch bookmarks data at the same time as the
changeset. This should be enough to avoid the one race condition that
this bookmark prefetching is trying to work around. It even allows
future server to make sure everything is generated from the same
"transaction" if they become capable of such. The current code was
already overwriting the prefetched value with the one in bundle2
anyway.  Note that this is not preventing all race conditions in
related to bookmark in 'hg pull' it makes nothing better and nothing
worse.

Reducing the number of listkeys calls will reduce the latency on pull.

The pre-fetch is also moved into a discovery step because it seems to belong
there.

(1) Because all servers not speaking 'pushkey' parts are compatible with the
'HG2X' protocol only.

--- a/mercurial/exchange.py	Thu May 28 14:01:53 2015 -0700
+++ b/mercurial/exchange.py	Wed May 27 04:57:03 2015 -0700
@@ -895,7 +895,6 @@
                     " %s") % (', '.join(sorted(missing)))
             raise util.Abort(msg)
 
-    pullop.remotebookmarks = remote.listkeys('bookmarks')
     lock = pullop.repo.lock()
     try:
         pullop.trmanager = transactionmanager(repo, 'pull', remote.url())
@@ -943,6 +942,16 @@
         step = pulldiscoverymapping[stepname]
         step(pullop)
 
+@pulldiscovery('b1:bookmarks')
+def _pullbookmarkbundle1(pullop):
+    """fetch bookmark data in bundle1 case
+
+    If not using bundle2, we have to fetch bookmarks before changeset
+    discovery to reduce the chance and impact of race conditions."""
+    if not _canusebundle2(pullop): # all bundle2 server now support listkeys
+        pullop.remotebookmarks = pullop.remote.listkeys('bookmarks')
+
+
 @pulldiscovery('changegroup')
 def _pulldiscoverychangegroup(pullop):
     """discovery phase for the pull