Re: [PATCH 1 of 4 V2] obsolete: track node versions
On 04/05/2017 11:37 PM, Durham Goode wrote: I respond inline, but I'm also happy to drop discussion about evolve-like user experience changes and instead focus on the proposal about just making hidden commits a separate system. So we can discuss the various topics incrementally. I think most of the important point raised in this email are already covered (or open) in the more fresh thread. So I'm going to drop this with the hope to save everyones time. Cheers, -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 4 V2] obsolete: track node versions
On 04/05/2017 03:30 PM, Ryan McElroy wrote: […] I strongly believe that going back into a long discussion or battle over how evolve should behave is a good use of anyone's time. Can't we just build out core hiding mechanisms and build experiences on top of that? We can each use this in the way we feel best. So, there seems to be a misunderstanding here. We already have a generic and extensible hiding API. For the past 4 years. In order to cut some heads of this threads hydra, please see and comment on my extended reply here. https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096294.html -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 4 V2] obsolete: track node versions
I respond inline, but I'm also happy to drop discussion about evolve-like user experience changes and instead focus on the proposal about just making hidden commits a separate system. So we can discuss the various topics incrementally. On 4/5/17 3:23 AM, Pierre-Yves David wrote: Summary --- I think we need to take an extra step back in the current discussion. We seems be get slowly lost in a sub branch of evolution design, discussing sub-concerns with a partial view of the big picture. Currently Evolution has: * an overall consistent design, * a planned final UI that allow to introduce complexity progressively, * a large and diverse base of tester providing useful feedback that prompt small adjustment and polishing, * a defined road-map, * resource and founding[1] (at least partially) to bring this plan to completion. They are currently no large unsolved problem in this plan that I'm aware of and no feedback from testers that would justify and overall full redesign of this plan. There are a few problems that I'm not aware of plans to solve: - unhiding commits (regardless of how they were hidden) - an intuitive user interface for explaining evolve concepts to users - the complexity the current obsmarker system enforces upon designing user experiences (ex: the discussion about unhiding commits required in depth understanding of obsmarker; and the discussion about hiding temporary commits during shelve required proposing a brand new, very specific concept to handle the case; and discussions around ux require in depth understanding of the various troubles) If you do not consider these to be problems (i.e. unhiding arbitrary commits is not a goal; or the current interface is intuitive; etc), I think other people do consider them to be problems. If we want to start large discussion impacting evolution we should start from the basic. What is unclear about the current plan? What is missing from the Roadmap? etc… We needs to have a common understanding of the situation before digging into building solutions. The proposal at hand disable a corner-stone of evolution (hiding of obsolete commit) that has been working well for years. To try solving undefined problem and helps with advances-corner-case like hash-preservation. This is the wrong kind of trade-off and a direction we should not pursue. The 3 bullets above are the problem I'm trying to solve. Trivial unhiding semantics, easy user interface with low conceptual overhead, and a design that makes discussions in this area easy to understand and reason about. I do not think the current solution has worked well for years, and I think the fact that it is still not in core and people still aren't able to understand discussions about it indicates that it is has deeper issues. I'm made more detailed comments about the actual proposal inline. [1] Thanks goes to Unity and Bitbucket for that. On 03/30/2017 08:28 PM, Durham Goode wrote: Let's step back a moment and think about what obsmarkers are used for. They are used to hide commits, and to automatically perform rebases. Actually this is a limited view of what evolve aims at, is and currently achieves. I'll try to find some time during the freeze to go over the existing documentation and clarify some of the core concepts and goal. If you can provide a concise bullet point list of the other goals of evolve, that would be useful in understanding where my proposal is flawed. My understanding is that, while evolve may have other benefits, the biggest ones are hiding and auto rebase, and having a simple solution to those problems will have a large impact on users by itself. The concerns around obscycles is that allowing cycles (without a perfect version scheme) could affect those two uses. For hiding, it could result in hiding commits from the user that they didn't mean to be hidden. For rebasing, it means we could rebase onto the wrong successor. While your conclusion are overall good according your premises, this analyses is missing multiples areas where obsmarker are used today (eg: troubles detections, checkheads post processing, etc). See my original reply to Jun proposal for a list of area to take in account while working on evolution related proposal. I think the fact that my user experience oriented proposal requires understanding "checkheads processing" highlights why I think we need to rethink these concepts. If I can't reason about auto rebase and hiding commits UX without having to understand what checkheads means, then the system is too complicated. I think the underlying issue is that we're trying to do too much magic for the user, and we're unable to find a perfect design to make that magic safe and understandable. I think finding the right answer here may be impossible. So far, testing show that automated behaviors of evolution are understood by testers and performing their duties (yes, they are some known case that needs adjustment). And we
Re: [PATCH 1 of 4 V2] obsolete: track node versions
On 4/5/17 11:23 AM, Pierre-Yves David wrote: Summary --- I think we need to take an extra step back in the current discussion. We seems be get slowly lost in a sub branch of evolution design, discussing sub-concerns with a partial view of the big picture. I agree. Overall, my feeling is that trying to redesign changeset evolution is not what we should be concentrating on. Currently Evolution has: * an overall consistent design, * a planned final UI that allow to introduce complexity progressively, * a large and diverse base of tester providing useful feedback that prompt small adjustment and polishing, * a defined road-map, * resource and founding[1] (at least partially) to bring this plan to completion. s/founding/funding :-p They are currently no large unsolved problem in this plan that I'm aware of and no feedback from testers that would justify and overall full redesign of this plan. If we want to start large discussion impacting evolution we should start from the basic. What is unclear about the current plan? What is missing from the Roadmap? etc… We needs to have a common understanding of the situation before digging into building solutions. The proposal at hand disable a corner-stone of evolution (hiding of obsolete commit) that has been working well for years. To try solving undefined problem and helps with advances-corner-case like hash-preservation. This is the wrong kind of trade-off and a direction we should not pursue. I'm made more detailed comments about the actual proposal inline. [1] Thanks goes to Unity and Bitbucket for that. On 03/30/2017 08:28 PM, Durham Goode wrote: Let's step back a moment and think about what obsmarkers are used for. They are used to hide commits, and to automatically perform rebases. Actually this is a limited view of what evolve aims at, is and currently achieves. I'll try to find some time during the freeze to go over the existing documentation and clarify some of the core concepts and goal. I agree that changeset evolution is a bigger concept. A lot of these proposals seem to miss that exchange is the hard part that evolution has concentrated on and gotten remarkably good at (I've actually used full-on evolve workflows in collaboration with Sean Farley while working on remote names, and it *actually works* when editing the same series of changesets! We probably shouldn't break all of this). The problems FB is trying to solve are actually less ambitious right now: we want to solve local-user workflows. We feel that changeset evolution has made some difficult choices in this area (like not reviving old hashes) that make single-user workflows harder to reason about, but these are choices it had to make to get the more ambitious plan to work well (granted, I don't claim to fully understand all the implications of obsmarker cycles -- I haven't had the cycles [heh] to deeply understand that yet). I think instead of fighting about the future of changeset evolution, we can concentrate on building the common infrastructure for hiding commits that we all want and need to be fast and scalable. Then we can build whatever experiences we want on top of that, using obsolescence, archiving, internal-phase, or whatever other concepts we come up with. We should be able to agree on an underlying system to do this in a performant and scalable way that lets other extensions do more experimental things with what gets hidden or unhidden. The concerns around obscycles is that allowing cycles (without a perfect version scheme) could affect those two uses. For hiding, it could result in hiding commits from the user that they didn't mean to be hidden. For rebasing, it means we could rebase onto the wrong successor. While your conclusion are overall good according your premises, this analyses is missing multiples areas where obsmarker are used today (eg: troubles detections, checkheads post processing, etc). See my original reply to Jun proposal for a list of area to take in account while working on evolution related proposal. I think the underlying issue is that we're trying to do too much magic for the user, and we're unable to find a perfect design to make that magic safe and understandable. I think finding the right answer here may be impossible. So far, testing show that automated behaviors of evolution are understood by testers and performing their duties (yes, they are some known case that needs adjustment). And we have a full plan to deliver that to all users. If you think they are problematic area or unsolved/unsolvable problems blocking that goal, can you be more specific and bring them up in a more top level discussion about the current evolution plan. Proposal === I propose a series of changes to reduce the magic and remove the need for obs versioning, while maintaining the power and increasing the understandability of these workflows. It has two parts: 1. Never hide a commit du
Re: [PATCH 1 of 4 V2] obsolete: track node versions
Summary --- I think we need to take an extra step back in the current discussion. We seems be get slowly lost in a sub branch of evolution design, discussing sub-concerns with a partial view of the big picture. Currently Evolution has: * an overall consistent design, * a planned final UI that allow to introduce complexity progressively, * a large and diverse base of tester providing useful feedback that prompt small adjustment and polishing, * a defined road-map, * resource and founding[1] (at least partially) to bring this plan to completion. They are currently no large unsolved problem in this plan that I'm aware of and no feedback from testers that would justify and overall full redesign of this plan. If we want to start large discussion impacting evolution we should start from the basic. What is unclear about the current plan? What is missing from the Roadmap? etc… We needs to have a common understanding of the situation before digging into building solutions. The proposal at hand disable a corner-stone of evolution (hiding of obsolete commit) that has been working well for years. To try solving undefined problem and helps with advances-corner-case like hash-preservation. This is the wrong kind of trade-off and a direction we should not pursue. I'm made more detailed comments about the actual proposal inline. [1] Thanks goes to Unity and Bitbucket for that. On 03/30/2017 08:28 PM, Durham Goode wrote: Let's step back a moment and think about what obsmarkers are used for. They are used to hide commits, and to automatically perform rebases. Actually this is a limited view of what evolve aims at, is and currently achieves. I'll try to find some time during the freeze to go over the existing documentation and clarify some of the core concepts and goal. The concerns around obscycles is that allowing cycles (without a perfect version scheme) could affect those two uses. For hiding, it could result in hiding commits from the user that they didn't mean to be hidden. For rebasing, it means we could rebase onto the wrong successor. While your conclusion are overall good according your premises, this analyses is missing multiples areas where obsmarker are used today (eg: troubles detections, checkheads post processing, etc). See my original reply to Jun proposal for a list of area to take in account while working on evolution related proposal. I think the underlying issue is that we're trying to do too much magic for the user, and we're unable to find a perfect design to make that magic safe and understandable. I think finding the right answer here may be impossible. So far, testing show that automated behaviors of evolution are understood by testers and performing their duties (yes, they are some known case that needs adjustment). And we have a full plan to deliver that to all users. If you think they are problematic area or unsolved/unsolvable problems blocking that goal, can you be more specific and bring them up in a more top level discussion about the current evolution plan. Proposal === I propose a series of changes to reduce the magic and remove the need for obs versioning, while maintaining the power and increasing the understandability of these workflows. It has two parts: 1. Never hide a commit during hg pull. Only hide commits when the user does an action (strip/rebase/amend/histedit/evolve) --- One of the recurring issues with obsmarkers is that commits may magically disappear when you pull from another repo. This is not something raised by current testers using full evolution and this is not a known weakness of the current design. So I'm not sure why you make it a high profile issue. This comes up often when discussing corner case impacted by proposal or as blocker for case were people wants to abuse obsolescence marker out of their primary usage. This also comes up in the unorthodox work-flow of the Mercurial project, but it is a work-flow issue on the Mercurial side. This has two issues: A) we have no good way of explaining it to the user, This does not match user feedbacks. And it does not seems hard to explain. Mercurial hide obsoletes changesets (changeset with a newer version (successors) or markers as pruned). (unless they have non-obsolete descendants). >and B) we can't even be sure the user wants those commits to disappear. The current set of evolution commands is designed to be intend-full. Testing has not shown large issue with them. As long as obsolescence markers are not used abusively. I propose we *never* hide a commit when doing hg pull. When the user pulls, we download the obsmarkers like normal, but the commits don't disappear. Instead, we show the "[amended|rebased] to HASH" text in a log/smartlog output so the user can know the old commits are dead, then they can strip them at their leisure. This has the added benefit of making it user visible what obsmarker changes the pull brought in.
Re: [PATCH 1 of 4 V2] obsolete: track node versions
I think this is a very nice approach to move forward. There are some behavior changes. But I've discussed with Durham and I'm happy about the new behaviors. The "node version" approach achieves "unhide" in a fast and more conservative way. The root-based hidden seems to require some non-trivial changes so I'll send a new version of "node version" patches solely to solve the "visibility" issue. Without a more general purposed API targeting future possibilities like exchange etc. Excerpts from Durham Goode's message of 2017-03-30 11:28:32 -0700: > Let's step back a moment and think about what obsmarkers are used for. > They are used to hide commits, and to automatically perform rebases. The > concerns around obscycles is that allowing cycles (without a perfect > version scheme) could affect those two uses. For hiding, it could > result in hiding commits from the user that they didn't mean to be > hidden. For rebasing, it means we could rebase onto the wrong successor. > > I think the underlying issue is that we're trying to do too much magic > for the user, and we're unable to find a perfect design to make that > magic safe and understandable. I think finding the right answer here may > be impossible. > > Proposal > === > > I propose a series of changes to reduce the magic and remove the need > for obs versioning, while maintaining the power and increasing the > understandability of these workflows. It has two parts: > > > 1. Never hide a commit during hg pull. Only hide commits when the user > does an action (strip/rebase/amend/histedit/evolve) > --- > > One of the recurring issues with obsmarkers is that commits may > magically disappear when you pull from another repo. This has two > issues: A) we have no good way of explaining it to the user, and B) we > can't even be sure the user wants those commits to disappear. > > I propose we *never* hide a commit when doing hg pull. When the user > pulls, we download the obsmarkers like normal, but the commits don't > disappear. Instead, we show the "[amended|rebased] to HASH" text in a > log/smartlog output so the user can know the old commits are dead, then > they can strip them at their leisure. This has the added benefit of > making it user visible what obsmarker changes the pull brought in. > > This proposal has two optional side features: > > 1a. *Do* hide commits during pull if the pulled version is public. > 1b. Add an option to strip/prune to auto hide any visible commits that > have visible successors and don't have visible descendants. So "hg pull > && hg strip/prune --obsolete-commits" would be roughly equivalent to hg > pull today. > > This proposal requires a notable change to core: > > - Hidden must be separated from obsmarkers storage and mutable outside > obsmarkers. This is possible with Jun's proposed phaseroot-esque hidden > storage. > > > 2. Auto rebase uses "visible successors" instead of "latest successor" > --- > > Today auto rebase (i.e. evolve) uses the latest successor as the > destination of the rebases. I propose we change that to "visible > successor" instead, where visible successor is defined as "any successor > commit that is not hidden". This means, regardless of the current > obsmarkers setup, the destination of the auto rebase is whatever > successor is currently visible. Which is probably what the user wanted > anyway. > > If there are multiple visible successors, auto rebase fails and shows a > list of the potential visible successors. Each item in the list can have > the "[amended|rebased] to HASH" string next to it so users can > understand at a glance the ordering and make a decision. They can either > use -d on rebase to specify a solution to the conflict, or they can use > the normal visibility commands (hg strip/prune) to remove any > undesirable commits. > > The presence of cycles does not affect this at all, and there is no need > for marker versioning. Auto rebase still uses whatever successors are > visible, even if the successor is "older" than it, because of a cycle. > The user can use the same rebase -d or strip/prune resolutions to > resolve the conflict. > > Summary of what these two changes achieve > === > > From a single, non-exchanging user's perspective the above proposal > does not affect current UX around when things are hidden (like during > rebase/amend/etc), but does allows all the benefits of the obscycle > discussion (allowing unhiding) without the need for obsmarker versioning. > > From an exchange user's perspective, this makes exchange much more > deterministic for the user (nothing is magically removed from the repo, > and what new obs information from the pull is explained via smartlog), > while still enabling auto rebase workflows. It also makes obsmarker > conflict (divergence/etc) easier to understand and resolve by allowing > users to resolve obsmarker conflicts using tools they're already > familiar with (rebase -d, st
Re: [PATCH 1 of 4 V2] obsolete: track node versions
On 3/30/17 11:28 AM, Durham Goode wrote: 1. Never hide a commit during hg pull. Only hide commits when the user does an action (strip/rebase/amend/histedit/evolve) 2. Auto rebase uses "visible successors" instead of "latest successor" To elaborate on how I see this obs cycle series affecting this proposal, I think the end result of this proposal is that obs versioning won't matter anymore. Or at the very least versioning only becomes a rough heuristic to suggest to the user which visible successor is likely to be their desired auto rebase destination. But, this series would be a fast way to introduce the concept of unhiding into core, which would let us start developing user experiences that benefit from unhiding, until we have truly separate hidden storage. So if we think my proposal is a good idea and where we want to be in the long run, I think we take this obscycle series, and don't worry about date being an imperfect heuristic since it won't matter in the long run. And we don't worry about the edge cases where it's unclear if X should be visible or Y, because in the future visibility will only ever be changed by explicit user action, and never by deducing it from obsmarker. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 4 V2] obsolete: track node versions
Let's step back a moment and think about what obsmarkers are used for. They are used to hide commits, and to automatically perform rebases. The concerns around obscycles is that allowing cycles (without a perfect version scheme) could affect those two uses. For hiding, it could result in hiding commits from the user that they didn't mean to be hidden. For rebasing, it means we could rebase onto the wrong successor. I think the underlying issue is that we're trying to do too much magic for the user, and we're unable to find a perfect design to make that magic safe and understandable. I think finding the right answer here may be impossible. Proposal === I propose a series of changes to reduce the magic and remove the need for obs versioning, while maintaining the power and increasing the understandability of these workflows. It has two parts: 1. Never hide a commit during hg pull. Only hide commits when the user does an action (strip/rebase/amend/histedit/evolve) --- One of the recurring issues with obsmarkers is that commits may magically disappear when you pull from another repo. This has two issues: A) we have no good way of explaining it to the user, and B) we can't even be sure the user wants those commits to disappear. I propose we *never* hide a commit when doing hg pull. When the user pulls, we download the obsmarkers like normal, but the commits don't disappear. Instead, we show the "[amended|rebased] to HASH" text in a log/smartlog output so the user can know the old commits are dead, then they can strip them at their leisure. This has the added benefit of making it user visible what obsmarker changes the pull brought in. This proposal has two optional side features: 1a. *Do* hide commits during pull if the pulled version is public. 1b. Add an option to strip/prune to auto hide any visible commits that have visible successors and don't have visible descendants. So "hg pull && hg strip/prune --obsolete-commits" would be roughly equivalent to hg pull today. This proposal requires a notable change to core: - Hidden must be separated from obsmarkers storage and mutable outside obsmarkers. This is possible with Jun's proposed phaseroot-esque hidden storage. 2. Auto rebase uses "visible successors" instead of "latest successor" --- Today auto rebase (i.e. evolve) uses the latest successor as the destination of the rebases. I propose we change that to "visible successor" instead, where visible successor is defined as "any successor commit that is not hidden". This means, regardless of the current obsmarkers setup, the destination of the auto rebase is whatever successor is currently visible. Which is probably what the user wanted anyway. If there are multiple visible successors, auto rebase fails and shows a list of the potential visible successors. Each item in the list can have the "[amended|rebased] to HASH" string next to it so users can understand at a glance the ordering and make a decision. They can either use -d on rebase to specify a solution to the conflict, or they can use the normal visibility commands (hg strip/prune) to remove any undesirable commits. The presence of cycles does not affect this at all, and there is no need for marker versioning. Auto rebase still uses whatever successors are visible, even if the successor is "older" than it, because of a cycle. The user can use the same rebase -d or strip/prune resolutions to resolve the conflict. Summary of what these two changes achieve === From a single, non-exchanging user's perspective the above proposal does not affect current UX around when things are hidden (like during rebase/amend/etc), but does allows all the benefits of the obscycle discussion (allowing unhiding) without the need for obsmarker versioning. From an exchange user's perspective, this makes exchange much more deterministic for the user (nothing is magically removed from the repo, and what new obs information from the pull is explained via smartlog), while still enabling auto rebase workflows. It also makes obsmarker conflict (divergence/etc) easier to understand and resolve by allowing users to resolve obsmarker conflicts using tools they're already familiar with (rebase -d, strip/prune). ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 4 V2] obsolete: track node versions
Per discussion on IRC. I'll drop this series from patchwork and send a new version with better documentation and some planned fixes. Excerpts from Jun Wu's message of 2017-03-27 01:49:03 -0700: > Thanks for the detailed reply. I have replies on multiple subtopics. But I > deleted topics that I think are less important, to make the most important > topic clear, and make the discussion more efficient. If you think I need to > respond to more topics, feel free to point me at them. > > Excerpts from Pierre-Yves David's message of 2017-03-27 09:14:53 +0200: > > [snip] > > > Simple practical example with date: > > --- > > > > [time-1] repo-B: changeset C-A is pulled from repo-A > > [time-2] repo-A: changeset C-A is rewritten as C-B (time-2) > > [time-3] repo-B: changeset C-C is marked as superceeded by C-A (time-3) > > [time-4] repo-B: Changeset C-B (with marker) is pulled from repo-A > > > > The markers pointing from C-B to C-A have a version "time-2" but "C-A" > > now have a version of "time-3". "C-A" become wrongly un-obsoleted (and > > I think we basically disagree here. You said that "C-A" being visible does > not match "the meaning of the user action", could you define "the meaning of > the user action" formally ? > > In the "node version" approach, the "meaning of a user action", where action > is "creating a marker", is defined as below: > > When the user replace changeset X with Y, the marker X -> Y gets created, > they want Y to be visible, regardless of what previous (local or remote) > attempts hiding it. > > So the un-obsolete behavior is expected. > > > C-B is in strange state). The fact C-A is un-obsoleted here is a bug and > > Strictly speaking, C-B still has an obsoleted precursor of C-A. If we draw a > 2-D graph, where Y-axis is revision, X-axis is time, and markers are edges, > the above case could be represented like: > >^ rev >| C-C >|\ >| C-A C-A >| \ >| C-B >| >+---> time > > Note that there are 2 "C-A"s, the right one is visible, the left one is not. > We show users the right one. Internally, the code could distinguish the > different of 2 "C-A"s, if it wants. > > > do not match the meaning of the user action. This is a regression from > > what evolution is currently able to achieve. > > [snip] ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 4 V2] obsolete: track node versions
Thanks for the detailed reply. I have replies on multiple subtopics. But I deleted topics that I think are less important, to make the most important topic clear, and make the discussion more efficient. If you think I need to respond to more topics, feel free to point me at them. Excerpts from Pierre-Yves David's message of 2017-03-27 09:14:53 +0200: [snip] > Simple practical example with date: > --- > > [time-1] repo-B: changeset C-A is pulled from repo-A > [time-2] repo-A: changeset C-A is rewritten as C-B (time-2) > [time-3] repo-B: changeset C-C is marked as superceeded by C-A (time-3) > [time-4] repo-B: Changeset C-B (with marker) is pulled from repo-A > > The markers pointing from C-B to C-A have a version "time-2" but "C-A" > now have a version of "time-3". "C-A" become wrongly un-obsoleted (and I think we basically disagree here. You said that "C-A" being visible does not match "the meaning of the user action", could you define "the meaning of the user action" formally ? In the "node version" approach, the "meaning of a user action", where action is "creating a marker", is defined as below: When the user replace changeset X with Y, the marker X -> Y gets created, they want Y to be visible, regardless of what previous (local or remote) attempts hiding it. So the un-obsolete behavior is expected. > C-B is in strange state). The fact C-A is un-obsoleted here is a bug and Strictly speaking, C-B still has an obsoleted precursor of C-A. If we draw a 2-D graph, where Y-axis is revision, X-axis is time, and markers are edges, the above case could be represented like: ^ rev | C-C |\ | C-A C-A | \ | C-B | +---> time Note that there are 2 "C-A"s, the right one is visible, the left one is not. We show users the right one. Internally, the code could distinguish the different of 2 "C-A"s, if it wants. > do not match the meaning of the user action. This is a regression from > what evolution is currently able to achieve. [snip] ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 4 V2] obsolete: track node versions
This is a group reply because there is interesting bit in many different
emails, see the final link section below for details about the email I
refer to using [#].
Two different issues
=
Just to clarify: there is two different issues at play here:
*unintentional-cycle*: cycle of obsolescence markers is an unavoidable
possibility inherent to the fact we deal with a distributed system.
*intentional-cycle*: an idea from Jun to use "node-version" and
obsolescence cycle to revive obsolete changesets while keeping the same
hash. So far, locally creating cycle have been disallowed since dealing
with cycle is advanced and complex. Jun proposed to lift this in this
series [1].
Some background
===
Jun and I had a short discussion Sunday late afternoon at the sprint
(referred in [2]). In that discussion, jun mentioned the idea of using
obsstore index to arbitrate cycle. At that point, I was thinking about
unintentional-cycle and I suggested digging in the direction of using
the "date" because it is a global property.
"unintentional-cycles" are expected to be "rare", dealing with them as
an error case that requires user intervention seems fine (as the rest of
instability handling). I dunno if using date will help presenting the
issue well to the end user, but that was at least a global properly so
any repo would see the same thing. Simplest handling I can think for
unintended cycle is (1) detect them (2) ask the user (3) create a
newnode (or maker but probably node) to record the solution (4) be done.
Main issue with current proposal: distribution
==
There is multiple issues with the current proposal, but here the main
one that looks like a definitive blocker.
The node version proposal introduces a new concept of version for "node"
and "markers" and some logic to disables all markers with a version
lower than the node it affect. ("dates" of marker are used as node
version, but the same issue stand with generation maker).
The core issue here have been pointed by Gregory Szorc in [4]. Since our
system is distributed, it is impossible to make sure the date/generation
have the meaning they attempt to have.
Simple practical example with date:
---
[time-1] repo-B: changeset C-A is pulled from repo-A
[time-2] repo-A: changeset C-A is rewritten as C-B (time-2)
[time-3] repo-B: changeset C-C is marked as superceeded by C-A (time-3)
[time-4] repo-B: Changeset C-B (with marker) is pulled from repo-A
The markers pointing from C-B to C-A have a version "time-2" but "C-A"
now have a version of "time-3". "C-A" become wrongly un-obsoleted (and
C-B is in strange state). The fact C-A is un-obsoleted here is a bug and
do not match the meaning of the user action. This is a regression from
what evolution is currently able to achieve.
The fact patch 3 of this series had to update the evolve tests is a good
example of how the current approaches break some simple assumption in
current evolution behavior.
Simple practical example with generation number:
Using generation number would make the simple example above works.
However they have the same class of issues in a sightly different way.
It is impossible to make sure the local generation number is in phase
with the other repositories. Here is another simple example using Jun
proposal to "revive" changesets:
repo-B: pull C-A from repo-A
repo-B: rewrite C-A as C-C (marker: A → B generation 0)
repo-B: undo the rewrite (marker: B → A generation 1)
repo-A: rewrite C-A as C-B (marker A → C generation 0)
repo-B: push C-A to repo-A (+ markers)
The markers pointing from C-B to C-A have a generation "0" but "C-A" now
have a version a generation of "1". "C-A" become wrongly un-obsoleted
(and C-B is in strange state). The fact C-A become un-obsoleted here is
a bug and do not match the meaning of the user action. This also a
regression from what evolution is currently able to achieves too.
Conclusion
--
Approaches based on node and marker versions are unable to cope with the
distributed nature of Mercurial and evolution. One looking for the
hash-preservation-stone should go down more viable alley
Further Though
--
Something based on ordering markers themselves -might- still be
something leading to a solution (as still pointed by Greg in [4]).
However, by definition, markers creations might happens in parallel at
the same time in multiple repositories, and their is no defined order
between the two "branches". The complexity of tracking -and- using this
information seems high at first glances. Jun is talking about possible
dag building in [5]. The various property of obsmarkers and their
combinations with the changesets dag makes me doubt of that having a
viable complexity for such DAG, but I'm not seen anything concrete about
Jun idea yet so he
