lothiraldan added a comment.
Hi Pulkit, Thanks for your patience. I had a couple of important things to get out of the way before I could turn my attention to this. I reached out to Ryan and he sent me the code he wrote at the 4.6 Sprint. I made it available here to support the discussion: https://phab.mercurial-scm.org/D4479. The core differences in his approach are to filter out obsmarkers affecting the "re-pulled" nodes instead of "stripping" those markers. The main benefit is to avoid information loss. Stripping markers will break the evolution history, preventing user to benefit from it. Filtering markers out mean that the history will be fully restored if the affected changeset get obsolete again. It can be triggered by the same events.This is a pure implementation detail, having the same user-level effect than the behavior proposed in this Proof of Concept series. Regarding the implementation of this series, I feel like the current detection code needs to move at a higher level. Having changegroup aware of obsmarkers at such a low level seems wrong and can lead to consistency issues if the bundle contains obsmarkers. An alternative approach would be to keep track of redundant incoming nodes during changegroup processing (on the transaction object as we are already doing for all new nodes), and process that list at the end of the transaction. We'll give a shot at such implementation, it is useful in other scenarios. To take a step back, I'm wondering what's the end goal? I remember there was a discussion about having rebase enabled by default, is it related? The behavior target by this series ("unobsolete" re-pulled changeset) conflicts with the final behavior we want for Changeset Evolution. Intermediate steps are a good way to make progress. I feel like it is important to write down a clear plan when it comes to adding behavior that does not match our final goals. How are we planning to transition from the local-only step to full (ie, distributed) Evolution? REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D2679 To: indygreg, #hg-reviewers Cc: lothiraldan, pulkit, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
