Per discussion on IRC with marmoute, this series lacks of documentation.

I'll drop it from patchwork and send a new version with better documentation
and some planned fixes. The next version has a same core idea, but the
interface is more formalized and is made future proof in mind. The interface
changes are by myself and haven't been discussed here.

Excerpts from Augie Fackler's message of 2017-03-23 18:05:45 -0400:
> On Mon, Mar 13, 2017 at 11:57:08AM -0700, Pierre-Yves David wrote:
> >
> >
> > 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
> >
> > * 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)
> 
> I've had a look over the code, and it's surprisingly simple (though it
> could probably use more comments for future code archaeologists.) I'm
> wary (as is indygreg) of using the date field for this sorting, just
> because clocks are known sources of evil and consternation.
> 
> (I acknowledge we might not have a significantly better choice though,
> although I'd like to give it some more thought.)
> 
> >
> > Cheers,
> >
> > --
> > Pierre-Yves David
> > _______________________________________________
> > 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

Reply via email to