lothiraldan added a comment.
In https://phab.mercurial-scm.org/D2679#70935, @durin42 wrote: > In https://phab.mercurial-scm.org/D2679#70934, @lothiraldan wrote: > > > In https://phab.mercurial-scm.org/D2679#69388, @durin42 wrote: > > > > > I'm slowly becoming convinced that the long-unquestioned axiom that "all markers are distributed globally" isn't correct, and this is part of why: it's potentially of great value to be able to restore a change by re-pulling it, even though the obsmarkers would normally cause it to be deleted. > > > > > > Avoiding silent reappearance of the locally obsolete changeset that we see on a remote repository is a core feature of obsolescence. Actually, it is the one issue that prompted the creation of changeset evolution in the first place. > > > There's a difference (in my view) between something accidentally coming back and intentionally coming back. The current state of affairs prevents both. I feel like we can do better. I feel like detecting if an obsolete changeset is re-added accidentally or intentionally is a near impossible problem. We have submitted code recently to detect when an obsolete changeset is re-added, but again we don't know if it is accidentally or intentionally. The safe path here is to inform the user about suspicious situations and give them the tool to explicitly restore changesets they want to be restored. That why we have been working on an explicit `hg rewind` command in evolve. > > >> We and the other people using distributed evolution rely on this behavior on a daily basis. The includes people who picked up the evolve extension on their own and came up with their own workflow without ever speaking to us. We can see some user interfaces adjustment in the future, but the set of synchronized markers and the associated behavior is something we are happy about. It has been well tested in diverse teams and situation for multiple years now. > > I've brought this up repeatedly and been dismissed with this exact argument every time. I weary of it, because it's not a new argument, it's just blind devotion to the initial design without any attempt at reflection if we can do better. Since I joined Octobus, I've witnessed the exploration of all the remaining uncharted territories and solving of most of the resulting associated challenges. In particular, some important aspects of distributed evolution: instabilities resolutions and efficient obsmarkers exchanges have been solved and have working implementations used on a daily basis. We did alter the initial design when deemed so by new information from exploration or feedback of evolve users. During these developments, we did not find reasons to challenge the obsolescence core concepts. They, in fact, proved a useful help to build solutions to the distributed evolution challenges. To name a few of these progress and design changes: vocabulary renaming, the missing commands for history exploration and reviving, the new discovery protocol and more recently how to track fold in obsmarkers. In a similar way, the numbers and types of distributed evolution users have grown and we had more and more opportunity to exchange with them. We base our plans on more than "some people using it without complains". They are a diverse and large corpus of people we have been talking to and studied their workflows. Here again, core concepts, in particular, the global state and instabilities are things that, practically helps teams to use distributed evolution workflows and newcomers to get a good grasp of it. Important behavior designed and tested in the past 5 years, like the exchange behavior, have been battle tested and real people rely on them in their day to day workflow. So, it might seem like the same argument, but it is actually a stronger one. The data to back it kept growing in the past couple of years. If you need more details, check our recent blog post about evolution: https://octobus.net/blog/2018-09-03-evolve-status-2018-08.html > I don't dispute that evolution as currently implemented is a good thing, but I feel like there's room for significant improvement while simultaneously simplifying the exchange algorithms. Care to try and convince me why I'm wrong, without anecdotal "many people use this and haven't complained" arguments? Sure, the proposal in this PoC ("unobsolete" all re-added changesets) break basic distributed evolution workflow very quickly. Here are small examples among many. They display simple draft changesets roundtrips: - Example A: - I am working on a repository with a changeset A that is present also on my default server - I amend A into A' - I pull from my default server, the server doesn't know yet that A has been rewritten into A'. A is sent by the server. - A is hidden before the pull. Getting A to be visible again would be confusing for me as I would now have both A and A' "alive" at the same time. - Example B: - I am working on a repository with a changeset A that is present also on my default server - I amend A into A' - One of my coworkers push a changeset B on top of A to the server - I pull from my default server - I receive both B and A, and I have all the needed information to stabilize B and continue my work. I don't want A to become "unobsolete" on pull. We can provide other examples if needed. Could you give some details about the improvements that you suggest and that what kind of core changes they would require and their effects on distributed evolution? REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D2679 To: indygreg, #hg-reviewers Cc: durin42, lothiraldan, pulkit, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
