[PATCH 0 of 3 STABLE] bundlerepo: make secret revisions visible, if bundle bases on current local repo

FUJIWARA Katsunori foozy at lares.dti.ne.jp
Thu May 30 03:32:55 CDT 2013


At Wed, 29 May 2013 17:48:42 +0200,
Pierre-Yves David wrote:
> 
> [1  <text/plain; iso-8859-1 (quoted-printable)>]
> On Wed, May 29, 2013 at 06:52:20PM +0900, FUJIWARA Katsunori wrote:
> > 
> > At Tue, 28 May 2013 18:20:11 +0200,
> > Pierre-Yves David wrote:
> > > 
> > > [1  <text/plain; iso-8859-1 (quoted-printable)>]
> > > On Tue, May 28, 2013 at 11:59:32AM -0400, Jordi Gutiérrez Hermoso wrote:
> > > > On 28 May 2013 11:02, FUJIWARA Katsunori <foozy at lares.dti.ne.jp> wrote:
> > > > > This patch series focuses on the inconsistency between "hg incoming"
> > > > > and "hg unbundle": "hg incoming" doesn't show the revisions in the
> > > > > bundle, even though they are restored by "hg unbundle", if they are
> > > > > descendant of secret ones in local repository.
> > > > 
> > > > I think this difference makes sense. I normally pull from bundles, not
> > > > use unbundle. If hg incoming doesn't show secret revisions but hg pull
> > > > gives me those extra revisions, I would be confused.
> > 
> > Oops ! I forgot to care about "hg pull" from bundle repo.
> 
> My point is incoming/pull from bundle should not be different from
> incoming/pull from other source. It's not clear to me is the current
> behavior is divergent of if the behavior you ar pushing is divergent.
> 
> Can you clarify that ?

I think:

  - revisions restored by "hg unbundle" should be visible at "hg
    incoming" (and maybe "hg pull") from bundle, even if revisions in
    bundle file are descendant of secret ones in local repository

    because "hg incoming" is often used to confirm incoming revisions,
    before "hg unbundle" execution.

  - but "hg incoming" from bundle combined with another repo shouldn't
    make secret revisions in another repo visible

    below should show all revisions in bundlefile.

        $ hg -R repo incoming bundle:repo+bundlefile

    but below shouldn't show revisions which are descendant of secret
    ones in "another" local repo

        $ hg -R repo incoming bundle:another+bundlefile

    because below doesn't show secret ones in "another"

        $ hg -R repo incoming another

  - so, my patch series uses "bundlepeer" with unfiltered localrepo,
    only when base repo of bundle is current local repo itself

    this seems not to be so strange, because all revisions in current
    local repo are visible to user, even if they are secret.


Difference between starting points below may cause unconvincing.

  - "bundle should not be different from incoming/pull from other
    source" (yours)

  - "incoming/pull from bundle file should not be different from
    unbundle" (mine)


> > Revisions in bundle, which are descendant of secret ones in local
> > repository, are still ignored at "hg pull" with this patch
> > series. I'll keep consistency between incoming/pull/unbundle in V2.
> > 
> > 
> > > Can you convince me it make more sense to hide them in other case ?
> > 
> > This problem was reported by the user using TortoiseHg.
> > 
> > He saved (maybe stripped) some revisions, which are descendant of
> > secret one, into bundle file and tried to restore them by "unbundle".
> > 
> > But he couldn't restore bundled revisions, because TortoiseHg checks
> > "incoming" result before "unbundle", and aborts "unbundle" if there is
> > no incoming revision.
> > 
> > I suggested him to use "hg unbundle" directly on CUI, and he finally
> > restored them successfully.
> > 
> > Even for CUI users, confirming revisions by "hg incoming" before "hg
> > unbundle" seems to be normal behavior, because bundle file is not
> > human readable like export/patch file.
> > 
> > Users may think that their revisions are lost by Mercurial, because
> > "hg incoming" shows "no incoming revision" on bundle file in the case
> > above.
> > 
> > So, IMHO, this should be fixed not in third party utilities but in
> > Mercurial core.
> 
> The behavior you describe is clearly an issue. I see two separeted bug
> here:
>
> 1) incoming does not warn about potential phase movement. You may be
>    pulling nothing but still changing phases//moving bookmark.
>
> 2) bundlepeer use local phase data only and does not force bundle
>    content as draft. So bundle changeset descendant of locally secret
>    changeset are seen as secret.

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp


More information about the Mercurial-devel mailing list