1. TortoiseHg
  2. TortoiseHg
  3. thg
  4. Issues
Issue #2497 resolved

TortoiseHg pulling in wrong Phase information after switching a remote repository to/from publishing (command line works)

Anonymous created an issue

This is by no means a critical issue, I have solved it for myself, but wanted to post here to be thorough.

I thought mercurial was having trouble pulling in draft changesets when I changed a remote repository to a non-publishing server. However, I noticed that the issue only appears in TortoiseHg. After a direct command line pull everything is working as expected.

It is my personal update pattern to run "incoming" and then accept changes from there. However, it didn't matter if it was from a direct "pull" or from "incoming" first.

I kept changing my remote repository to and from a publishing server. TortoiseHg had trouble in both directions until I pulled from command line. i.e. After just removing "publish = False", TortoiseHg would still pull in draft changesets and vice versa for adding "publish = True".

Here is the mercurial issue that led me here: http://bz.selenic.com/show_bug.cgi?id=3863

Comments (7)

  1. Steve Borho

    I guess pulling from a bundle does not update phases the same way pulling from the upstream repository does? Makes sense, the phase info is not stored in the bundle, it is handled through the pushkey mechanism.

  2. Yuya Nishihara

    incomingbundle: extension to forward listkeys to source (refs #2497, #3582)

    Since hg e7fcf58acd71, bundle revisions are always set to draft phase. This change causes serious problem in TortoiseHg because our incoming->pull operation relies on the bug that bundle revisions had the same phase as their nearest ancestor, which was "public" in most cases.

    The incomingbundle extension works around it by forwarding "listkeys" request to the source repository.

    → <<cset 2125fdd2d1d1>>

  3. Yuya Nishihara
    • changed status to open

    sync: drop incomingbundle hack that can't handle phase movement (fixes #4060)

    Phase movement are applied to pullop.pulledsubset, which contains all local heads because they are common between local and bundle repositories. Therefore, all local changesets are bumped to public incorrectly.


    It seems not possible to simulate phase movement by simple extension, so we'll need to change the way to pull incoming changesets without using HG10 bundle.

    (backed out changeset 227c8f165a97, 2125fdd2d1d1, reopens #2497, #3582)

    → <<cset de5e1a16eeb8>>

  4. Yuya Nishihara

    sync: do not trust incoming bundle, just re-pull (fixes #2497, #3582, #3847)

    There were several problems caused by incoming + pull bundle since pushkey mechanism was introduced:

    • pulling in wrong phase (#2497)
    • bookmarks are not pulled (#3582)
    • largefiles cannot be packed into bundle (#3847)

    Furthermore, the situation got worse as bundle revisions are always set to draft since Mercurial 3.3. I don't expect that it will get better soon even if the new bundle format is available, because "pull bundle" seems not a first-class feature of hg.

    So, this patch drops support for "hg pull" from incoming bundle. Further cleanups should go on default branch.

    → <<cset 8e06560a847a>>

  5. Log in to comment