[Bug 4689] New: pulling a bookmark using 'hg pull --rev BOOKMARK' is racy

[mercurial-bugs at selenic.com]

http://bz.selenic.com/show_bug.cgi?id=4689

          Priority: normal
            Bug ID: 4689
                CC: mercurial-devel at selenic.com
          Assignee: bugzilla at selenic.com
           Summary: pulling a bookmark using 'hg pull --rev BOOKMARK' is
                    racy
          Severity: bug
    Classification: Unclassified
                OS: Linux
          Reporter: pierre-yves.david at ens-lyon.org
          Hardware: PC
            Status: UNCONFIRMED
           Version: default branch
         Component: bookmarks
           Product: Mercurial

Simple case pull -B
-------------------

The current flow for pulling a bookmark using 'hg pull --B BOOKMARK' is.

1) get remote host bookmarks
1.5) use the value as target (in pull command)
2) get remote host bookmarks (to be stored by the pull process)
3) get the changesets
4) update our local bookmarks.

There is a race condition between (1) and (3) (also with (2) but whatever).

If the bookmark is updated remotely between (1) and (3) we are going to pull
the former location of <bookmark> but won't be able to assign <bookmark> to it.

I think we should, only run (1) if we are going to use a bookmarks (-B), reuse
the value in the pull process.

Complex case pull -r
--------------------

1) use remote.lookup('bookmarkname') to get a target
2) get remote host bookmarks (to be stored by the pull process)
3) get the changesets
4) update our local bookmarks.

We have same race condition between (1) and (3), but we did not explicitly
retrieved it from bookmark data and we have no idea if this name was a
bookmark, a tag, or a branch.

Non directly related elements
-----------------------------

(2) exist to read bookmarks before changegroup generation to ensure we get the
remote bookmark data relevant at the time of its generation. Otherwise, we
could pull have:

- pull changesets
- remote get new changesets + move bookmarks
- pull bookmarks, nodes unknown

(2) can be handled better using bundle2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.