Any way to force obsolete exchange for a revision?

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Aug 2 14:11:18 UTC 2016


Mercurial exchange marker relevant to the set of changeset exchanged.
You widespread use of prune is probably confusing things around here.

You can find some details about what "relevant to the set of changeset
exchanged" here:


https://www.mercurial-scm.org/wiki/ObsolescenceMarkersExchange#Exchanged_markers_changes

On 08/02/2016 03:31 PM, Scott Bilas wrote:
> We're running into what must be a bug or two. I tried a very simple
> repro and the problem didn't occur, so I'm at a loss for the actual
> cause. Here's what we did, simplified as much as possible:
> 
>    1. Jonas commits as branch 'base', then as child branch 'derived' and
> pushes all of those to our shared evolve-enabled repo
>    2. Simon pulls 'base' and does a `rebase --keep` to a new parent,
> reviews it, does a fix commit, then prunes the old stuff
>    3. Simon does a `push -b.` to the shared repo. Commits are added, but
> the obsolete tags are not added. (bug?)
>    4. Ulf (who also just has 'base') pulls base from the shared repo and
> is surprised to see the old commits
>    5. Simon pulls 'derived', discovers the instability, evolves it. He
> pushes everything and now it shows the obsolete tags being added to the
> shared repo.
>    6. Ulf pulls 'base' again, but still has the same problem of old
> commits not pruned.
>    7. We create a new clone and pull 'base', and it only pulls the new
> commits as we would expect.
>    8. We try deleting obsstore and pulling again, same result. Plenty of
> obsolete markers are pulled, but not the ones we expect for 'base'.
> 
> Running with pull --debug returns the results I've pasted at bottom.
> This occurred with evolve 5.4.0 on hg 3.7.3. We've also tried evolve
> 5.4.1 on newer hg's with no change.
> 
> There seems to be a bug that has gotten us into this situation, which
> I'm interested in understanding. But even more important is how we get
> out of it. I can't figure out how to force evolve to pull those obsolete
> markers to my local clone. Is there any way to tell the system "pull
> 100% of obsolete markers"?
> 
> The only workaround I can think of is disabling evolve and stripping
> those commits.
> 
>>>>
> sending hello command
> sending between command
> remote: 543
> remote: capabilities: lookup changegroupsubset branchmap pushkey known
> getbundle unbundlehash batch streamreqs=generaldelta,revlogv1
> bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Aobsmarkers%3DV0%2CV1%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
> unbundle=HG10GZ,HG10BZ,HG10UN httpheader=1024 _evoext_obshash_0
> _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0
> _evoext_obshash_1 _evoext_getbundle_obscommon largefiles=serve
> remote: 1
> sending lookup command
> no changes found
> sampling from both directions
> query 1; still undecided: 241535, sample size is: 200
> sending evoext_obshash1 command
> 1 total queries
> sending getbundle command
> bundle2-input-bundle: with-transaction
> bundle2-input-part: "listkeys" (params: 1 mandatory) supported
> bundle2-input-part: total payload size 773
> bundle2-input-part: "listkeys" (params: 1 mandatory) supported
> bundle2-input-bundle: 1 parts total
> checking for updated bookmarks
> <<<
> 
> Scott
> 
> 
> 
> _______________________________________________
> Evolve-testers mailing list
> Evolve-testers at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
> 

-- 
Pierre-Yves David



More information about the Evolve-testers mailing list