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
