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 <qu...@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@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel