[PATCH 4 of 4 V2] obsolete: allow cycles

[Augie Fackler]

On Mon, Mar 13, 2017 at 12:25:25PM -0700, Jun Wu wrote:
> Excerpts from Pierre-Yves David's message of 2017-03-13 11:57:08 -0700:
> >
> > On 03/13/2017 09:23 AM, Durham Goode wrote:
> > > On 3/13/17 2:48 AM, Jun Wu wrote:
> > >> # HG changeset patch
> > >> # User Jun Wu <quark at fb.com>
> > >> # Date 1489395002 25200
> > >> #      Mon Mar 13 01:50:02 2017 -0700
> > >> # Node ID 6ae6d1069ba1d4089afaeb0bb8ef2411983a1292
> > >> # Parent  0280ee091bd0ae33aa0a67b0c8a55ccffd2e0718
> > >> # Available At
> > >> https://bitbucket.org/quark-zju/hg-draft
> > >>
> > >> #              hg pull
> > >> https://bitbucket.org/quark-zju/hg-draft
> > >> -r 6ae6d1069ba1
> > >> obsolete: allow cycles
> > >>
> > >> Now we can handle cycles nicely, allow them to be created. Some practical
> > >> examples:
> > >>
> > >>   - To revive X, just create a marker X -> X, with a newer date.
> > >>   - To prune X again, just create a marker X -> (), with a newer date.
> > >>   - The above two could be repeated.
> > >>
> > >>   - To unamend A -> B, just create a marker B -> A, with a newer date.
> > >>
> > >> It's now possible for "touch" and "unamend" to reuse hashes (therefore
> > >> more
> > >> user-friendly). And it's no longer necessary to write "*_source" in
> > >> commit
> > >> metadata to workarounds obs cycles. The hacky inhibit extension also
> > >> becomes
> > >> unnecessary.
> > >>
> > >> Finally. I have been wanting all these for a long time.
> > >
> > > Seems pretty elegant, though I haven't fully understood it yet. Maybe
> > > you guys talked about this in person, but what effect (if any) does this
> > > have on exchange?
> >
> > We did not really discuss this at the sprint :-/
> >
> > This probably has effect on two aspects of pull and push:
> >
> > * Computation of the relevant markers for a None
>
> Note sure what "None" means here.

I think he meant "node".

>
> Just want to mention, in terms of exchange, we have 2 choices:
>
>   1. Exchange the filtered markers.
>   2. Exchange the unfiltered markers.
>
> I think either will work. 1 is simpler because we don't need to introduce
> a separate "unfiltered" layer. 2 may be nicer if people want the full
> history of evolution.
>
> > * Computation of "head replacement" when pushing branches obsoleting
> > another one.
> >
> > The proposal have some very interesting aspect, I'll try to do a deep
> > review of its impact on the general concept soon™ (probably not this week)
> >
> > Cheers,
> >
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel