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

[Pierre-Yves David]

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 ?

> 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.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130529/f87eb059/attachment.pgp>