[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