Difficulties with permanence of obsolete markers
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Tue Jul 19 02:59:44 UTC 2016
On 06/28/2016 09:59 AM, Scott Bilas wrote:
> We're using evolve on my team, and are having difficulty with obsolete
> being a permanent one-way operation. (Unless I'm missing an evolve
> feature that lets us undo this, though I scanned the help and could not
> find anything..)
>
> Everything we do in hg for a non-evolve local repo is reversible, like
> changing phase, applying and stripping patches.. Yet if someone
> accidentally prunes/rebases/histedits the wrong thing in their
> evolve-enabled local repo, there's no going back. We're forced to
> 'touch' it back into existence, and then this has repercussions for the
> rest of the team once pushed, because new hashes.
>
> I assume what we're running into is an explicit design decision to avoid
> instability. The end result is that it's making our people very
> tentative about doing hist editing and fully trusting evolve.
There is a core principle on which evolve in built, "append only" data.
To work sanely in a distributed environment, it is much simpler to
always add new data and exchange the missing one with peer who have
less. This is why most of the workflow will avoid stripping things.
That said, evolution is still experimental and the user experience
lacking a lot in some area (like the one you are hitting).
> Our 'solution' so far to undo addition of obsolete markers has been the
> nuclear option: re-clone. That's the only way we know of to avoid the
> local obsolete markers poisoning the server on next push.
As Lars Westerhoff pointed out, you know have a surgery tool in `hg
debugobsolete` to remove some specific marker. As you pointed out this
is cumbersome and error prone, this is why we are planning to have `hg
strip` able to remove obsolescence marker alongside commits. This should
help with your current struggle a bit.
I'm not sure when this feature will land. A facebooker was planning to
tackle this, but I'm not sure what the state of things are.
> Am I misunderstanding anything about evolve here? Any guidance on how we
> can improve our workflow?
Something that emerged from evolve beta testing is that there is things
you "can edit" (draft) but probably should not (eg: other people
changesets, things currently in review). We'll likely grow some
mechanism to warn the user about probably harmful action, requiring
extra confirmation for the operation.
Something quite similar currently in the making is the detection of edit
that will create divergence, preventing user to shoot themselves in the
foot by default. For there will likely expand the logic to fit more
case. Eventually this should help your usecase more definitely.
I hope this message helped you getting a grasp of how much of your
struggle is by design and how much is by partial implementation.
Cheers,
--
Pierre-Yves David
More information about the Evolve-testers
mailing list