Excerpts from Pierre-Yves David's message of 2017-03-27 09:17:59 +0200: > > On 03/26/2017 08:41 PM, Jun Wu wrote: > > # HG changeset patch > > # User Jun Wu <qu...@fb.com> > > # Date 1490552007 25200 > > # Sun Mar 26 11:13:27 2017 -0700 > > # Node ID b6766d75404fb8c5d26af016caa76f44b47ce156 > > # Parent 336512ee2f947f07149e399a84927f9d820d2b62 > > # Available At https://bitbucket.org/quark-zju/hg-draft > > # hg pull https://bitbucket.org/quark-zju/hg-draft -r > > b6766d75404f > > histedit: revive commits on demand > > > > This is to address the "histedit --abort" issue mentioned in [1]. > > There are still issues with that approach. For example in this > distributed case: > > 1) Alice send changesets to Bob, > 2) Bob try to histedit something in the stack, this fails > 3) Bob --abort the histedit > 4) Bob tell Alice to perform the operation herself since she know the > code better and can resolve the conflict > 5) Alice histedit with success
Good example. But that's easily solvable by not writing the "parent" information when creating the markers, so the markers won't get exchanged. > If step (3) created markers for the histedit partial result, these > markers will apply to the result of (5) and create confusion/change > "loss" when the two states are gathered. > > This is a non-trivial question and there is good reason why rebase and > histedit do not use obsolescence marker to restore the repository to its > former state. > > note: this is a case were a local-light-weight "archiving" mechanism > could be handy. > > > This solution is safer than what [1] proposed because it does not use unsafe > > history writing ("strip"). The "strip" has caused several repo corruptions > > in production. > > I'm sure upstream would be happy to have some bug report about this and > maybe some investigation about this corruption. Strip corrupting > repository would happily rank a "critical". > > > It's similar to what "hg touch" in mutable-history does [3], without using > > random number. So it could be more reliably tested. > > The reason why 'touch' use random number is to ensure operation in one > repository will not -unexpectedly- affect the one in another repo (kind > of like here). We could use sometimes else than random but it cannot be > a simple sequential number. > > Note that using random will not solve the issue here since (5) does not > even know yet that the markers in (3) exists. > > > Note that if we have obsolete marker versions, and obsoleted revisions are > > revived automatically, as I proposed in [2], the "revive" hack will be > > longer be necessary. > > Please see my (fresh) reply to that other series. > _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel