[PATCH 3 of 3] histedit: revive commits on demand

Jun Wu quark at fb.com
Mon Mar 27 06:29:43 EDT 2017


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 <quark at 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.
> 


More information about the Mercurial-devel mailing list