quark added a comment.
In https://phab.mercurial-scm.org/D1082#19507, @lothiraldan wrote: > I'm still concerned about possible obsmarkers explosion as we move to more and more auto-stabilizing commands in core. For leaving a trace of the problem, if we use auto-stabilizing commands on every changeset on the stack (rewrite the first changeset, all parent get stabilized, rewrite the second changeset, all parents get stabilized, etc..), we will end up creating N²/2 obsmarkers with a stack of N: > > stack of 4 changeset: 8 obs-markers, > stack of 10 changesets: 50 obs-markers, > stack of 30 changesets: 450 obs-markers, > > > I'm not saying that everyone has a 30 changesets stack but even with a small stack going back and forth in the stack while making editions would rapidly grow the number of obsmarkers created which will cause scalability issues when exchanging markers. > > There is a couple of interesting lead to solve this, maybe we could do something special when more than X (configurable) obs-markers are created. Probably avoid the stabilization and point to some documentation or commands (like restack). In my opinion, the "obsmarkers explosion" problem is because the current algorithm loads the entire obsstore while it is not necessary to know all markers in all cases. i.e. "obsmarkers explosion" is NOT a problem if the algorithm is smarter that only parses or loads markers needed for certain calculations. i.e. `obsolete()` and all obsmarker-related revsets are lazy. Of course it takes some time to rewrite them into lazy versions. In additional, the `N^2` case you are talking about only happens if the user splits every commit in their draft stack, which is unrealistic. I don't think that should block the default behavior here. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D1082 To: quark, #hg-reviewers Cc: lothiraldan, martinvonz, dlax, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
