[PATCH 4 of 8] template: add minimal obsfate template function

[Boris Feld]

On Wed, 2017-08-09 at 22:42 +0900, Yuya Nishihara wrote:
> On Tue, 08 Aug 2017 18:48:08 +0200, Boris Feld wrote:
> > On Wed, 2017-08-09 at 00:19 +0900, Yuya Nishihara wrote:
> > > On Mon, 07 Aug 2017 16:56:23 +0200, Boris Feld wrote:
> > > > + at templatekeyword("succsandmarkers")
> > > > +def showsuccsandmarkers(repo, ctx, **args):
> > > > +    """Returns a list of dict for each final successor of ctx.
> > > > +
> > > > +    The dict contains successors node id in "successors" keys
> > > > and
> > > > the list of
> > > > +    obs-markers from ctx to the set of successors in "markers"
> > > > +    """
> > > > +
> > > > +    values = obsutil.successorsandmarkers(repo, ctx)
> > > > +
> > > > +    if values is None:
> > > > +        values = []
> > > > +
> > > > +    return showlist('succsandmarkers', values, args)
> > > 
> > > I think returning a list of successor nodes is more natural.
> > > 
> > > Can we theoretically gather the relevant markers from successor
> > > nodes?
> > > If the "markers" field serves just as a cache, it could be stored
> > > in
> > > revcache[] and passed to obsfate() under the hood.
> > 
> > The current algorithm for computing the successors sets of a
> > changeset
> > is this one:
> > 
> > Walk the obs-marker graph starting at a given revision. Follow
> > successors of each revisions walked until revisions has no more
> > successors, they are stable and they are the tip-most successor of
> > the
> > initial revision.
> > 
> > Having the sets of successors doesn't helps because a successor
> > could
> > be successor for more than one obsolete revision (fold for
> > example).
> 
> Thanks for clarifying that. So markers are tied to each successorset?
> 
>   successorssets(rev) -> [(succs0, markers0), (succs1, markers1),
> ...]

Yes markers are tied to each successorset.

> 
> In which case, {successorsset} could populate markers by makemap(),
> 
>   successorssets % "{successorset} {obsmarkers}"
>                                    ^^^^^^^^^^^^
>                                no idea how this should be rendered,
> but
>                                let's revisit it later.

I tried modifying successorssets to smuggle the markers via makemap but
it has one limitation.

In the case of pruned commits, we would have an empty successorsset but
at least one marker (the marker for pruning). Adding markers via
makemap would make the following condition: if(succsandmarkers, ...)
false for pruned markers.

I propose to keep succsandmarkers but hex all node ids so we would
never see binary information.

> 
> and perhaps obsfate could take the pair explicitly or implicitly.
> 
>   successorsets % "{obsfate(successorset, obsmarkers)}"  # a function
>   successorsets % "{obsfate}"  # a keyword available only in
> successorsets
> 
> obsfate could be even split to verb/users/mindate/maxdate.
> 
>   successorsets % "{obsverb} {obsusers} ..."
>                    ^^^^^^^^^^^^^^^^^^^^
>                  these keyword functions may be populated by
> makemap(), too.

I tried splitting obsfate into several functions and it looks nicer. I
prefer functions instead of keywords because keywords feels too magic,
do we have already some keywords that are similar (not taking context
as inputs) in core?

I have a rough series splitting obsfate(succsandmarkers) into
obsfateverb(successorset, markers), obsfateusers(successorset,
markers), ... Should I finish it and send a V2?
> 
> > The list of markers between a revisions and its successors could be
> > cached, I'm not sure how to use revcache for that. Did you meant
> > returning a hybrid object like this one, with a non-null revcache
> > parameter: https://www.mercurial-scm.org/repo/hg/file/tip/mercurial
> > /tem
> > platekw.py#l641?
> 
> Something like showlatesttag() or showfile*() was in mind, but
> "revcache"
> seems not the right tool as the markers aren't bound to the current
> rev.