hg clone --uncompressed do not clone obsmarkers so all obsoleted changesets are back to life (public phase)

Long Vu long.vu at intelerad.com
Mon Oct 1 14:40:19 UTC 2018


Hi,

Is there a draft version of 4.8 that transfer phase properly during clone
--uncompressed that I can test?

I had 2 theories for the problem: phase not transfered or obsmarkers not
transfered.

If phase transfer fix my problem then you guys do not have to spend time on
obsmarkers.

Thanks for the follow up!

Long



On Oct 1, 2018 06:15, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org>
wrote:

Hi Long Vu,

Thanks for reporting this bug. The phases data were indeed not exchanged
during the stream clone, this should be fixed in 4.8.

The issue with obsmarkers exchange remains, Anto Shestakov is currently
looking into it.


On 8/14/18 6:14 PM, Long Vu wrote:

> Hi Faheem,
>
> Thanks for looking into this, reply below.
>
>
> On Mon, Aug 13, 2018 at 5:20 PM, Faheem Mitha <faheem at faheem.info <mailto:
> faheem at faheem.info>> wrote:
>
>
>     On Mon, 13 Aug 2018, Long Vu wrote:
>
>         Hi,
>
>
>         I was wondering if this is by design or a bug.
>
>
>         If we hg clone --uncompressed (because --uncompressed is an
>         order of magnitude faster for big repos on generaldelta format)
>         all the previously obsoleted changesets are back to life (public
>         phase).
>
>
>         This behavior is different than hg clone without --uncompressed
>         which only clone not obsoleted changesets and will keep the
>         draft phase accordingly.
>
>
>         Is there a way to force re-transfer all the obsmarkers after an
>         hh clone --uncompressed?
>
>
>         Thanks,
>
>
>     It sounds like a bug to me. I can't see any reason why
>     --uncompressed should cause such different behavior. But can you
>     write a small reproduction recipe?
>
>
> You just need a repo on the server with commits still in draft phase.
>
> hg clone --uncompressed of that repo and all those commits in draft phase
> turned public phase.
>
> And hg clone without --uncompressed and all those commits in draft phase
> will stay draft.
>
>
>
>     I suppose you have publish = False set for phases locally? I.e.
>
>          [phases]
>          publish = False
>
>
> I do not set "phases.publish = False" locally.
>
> As far as I understand, we only need to set "phases.publish = False" on
> the server.  Or has evolve workflow requirement changed?
>
>
>     in .hgrc. I'd check with the developers on IRC (#hg-evolve on
>     freenode), and if they agree it is a bug, I would report a bug to
>     the Mercurial bug reporting system.
>
>     Regards, Faheem Mitha
>
>
> Let me know the BZ number once you logged it.  Thanks.
>
>
> --
> Long Vu | Software Developer, Tools & Infrastructure | Intelerad |
> +1-514-931-6222 ext. 7743
>
>
> This email or any attachments may contain confidential or legally
> privileged information intended for the sole use of the addressees. Any
> use, redistribution, disclosure, or reproduction of this information,
> except as intended, is prohibited. If you received this email in error,
> please notify the sender and remove all copies of the message, including
> any attachments.
>
>
> _______________________________________________
> Evolve-testers mailing list
> Evolve-testers at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
>
>
-- 
Pierre-Yves David

-- 


This email or any attachments may contain confidential or legally 
privileged information intended for the sole use of the addressees. Any 
use, redistribution, disclosure, or reproduction of this information, 
except as intended, is prohibited. If you received this email in error, 
please notify the sender and remove all copies of the message, including 
any attachments.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20181001/4d6e23ff/attachment-0002.html>


More information about the Evolve-testers mailing list