Internal-changeset concept

[raf at durin42.com]

On Mon, Apr 03, 2017 at 12:55:41PM -0700, Durham Goode wrote:
>
>
> On 4/3/17 4:11 AM, Pierre-Yves David wrote:
> > On 04/02/2017 05:56 AM, Jun Wu wrote:
> > > IIRC at the sprint that people tend to agree on root based hidden
> > > separated from phase root.
> >
> > There seems to be a large confusion here. This thread is talking about
> > "internal" changeset only. As explain in my two previous large emails,
> > in practice, today, the "internal" changeset operate in their own
> > "space" and the users do not need to care about them. Their various
> > properties make phases a possible option and even probably a good choice.
> >
> > This is -distinct- from what we have discussed at the sprint: local-only
> > hiding of changeset in the -real-space-. I've been part of these people
> > cautious about using phases for local-only-hiding on changesets in the
> > -real-space-, but this proposal is unrelated and does not contradict it.
> > Local-hidding still needs its own solution.
>
> While I understand that you're referring to a specific use case here, I
> think introducing a distinction between internal commits and normally hidden
> commits adds unnecessary conceptual overhead and complexity. I think we
> should avoid making that distinction, and instead head towards a world where
> hidden is a single unified concept, separate from obsolescence, and
> therefore we shouldn't go down the path of introducing new concepts like
> internal-commits right now.
>
> In the mean time though, having an API for hiding commits seems like a
> reasonable API regardless of its eventual implementation. Since obsolescence
> is the only way we have of hiding commits today, and since shelve's abuse of
> transactions is so terrible, I am in favor of introducing this API, then
> changing the implementation later when we've developed a better story for
> hiding. This way we can at least move all current 'bad' uses of obsolescence
> (i.e. uses that are just for hiding commits) to this new API, and they can
> be easily migrated to the future hiding mechanism.

I'm lightly in favor of this plan, with the caveat that I'd like more
certainty (read: a brief[0], clear, and concrete plan) around the
future of hiding things and what that means before we take the
API. I'm actually pretty lost right now and would appreciate an
executive summary of the state of where we think this is headed from
someone involved. Right now the overhead of getting up to speed on
this is so high that I'm not sure when I'll have a sufficiently large
block of time to read the body of text that's been produced in the
last two weeks. :(

0: no more than 2 printed pages, let's say.

>
> From a timeline perspective, I expect us to work on the hidden root feature
> within the next 2-3 months, so we're not kicking the can too far down the
> road.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel