On Wed, 2017-08-09 at 00:19 +0900, Yuya Nishihara wrote:
> On Mon, 07 Aug 2017 16:56:23 +0200, Boris Feld wrote:
> > # HG changeset patch
> > # User Boris Feld <boris.f...@octobus.net>
> > # Date 1501850856 -7200
> > #      Fri Aug 04 14:47:36 2017 +0200
> > # Node ID a96edc5bcdc8790719e003eefff91a4f656cc559
> > # Parent  e3f0339b83553039dcd87b62dc1dfbdf98548792
> > # EXP-Topic obsfatetemplate
> > template: add minimal obsfate template function
> 
> (Only reviewed the template stuff, since I haven't got so involved in
> obsolete
> naming, the operation metadata, etc.)
> 
> > +def successorsandmarkers(repo, ctx):
> > +    """compute the raw data needed for computing obsfate
> > +    Returns a list of dict, one dict per successors set
> > +    """
> > +    if not ctx.obsolete():
> > +        return None
> > +
> > +    ssets = successorssets(repo, ctx.node(), closest=True)
> > +
> > +    values = []
> > +    for sset in ssets:
> > +        values.append({'successors': sset, 'markers':
> > sset.markers})
> > +
> > +    return values
> > diff -r e3f0339b8355 -r a96edc5bcdc8 mercurial/templatekw.py
> > --- a/mercurial/templatekw.py       Mon Jul 03 03:27:58 2017 +0200
> > +++ b/mercurial/templatekw.py       Fri Aug 04 14:47:36 2017 +0200
> > @@ -655,6 +655,21 @@
> >      return _hybrid(gen(data), data, lambda x: {'successorset': x},
> >                     lambda d: d["successorset"])
> >  
> > +@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).

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?

> 
> > +@templatefunc('obsfate(succsandmarkers)')
> > +def obsfate(context, mapping, args):
> > +    """ Compute obsfate related information based on successors
> > and markers
> > +    """
> > +    data = args[0][0](context, mapping, args[0][1])
> > +    data = obsutil.computeobsfate(data['successors'],
> > data['markers'])
> 
> It has to check the number and types of the arguments. And please use
> evalfuncarg().

Thank you, I was looking for a cleaner way to do it. I will send a V2
after I fixed the return value of showsuccsandmarkers. 

I will send a separate series to clean join, I used it as example.

> 
> > +    _hybrid = templatekw._hybrid
> > +
> > +    # Format the successors for displaying
> > +    succs = _hybrid(None, data['successors'],
> > +                    lambda x: {'ctx': mapping['repo'][x],
> > 'revcache': {}},
> > +                    lambda d: templatekw._formatrevnode(d['ctx']))
> > +    data['successors'] = succs
> > +
> > +    return _hybrid(None, [data], lambda x: x, ', ')
> 
> [...]
> 
> > +  |/     Obsfate: [{"markers":
> > [["\udca4h\u071b63\udc8b\u0014\udcfd\udcb7\udc82_U\udcce=\udcf4\udc
> > e7\u0015\u0017\udcad"
> 
> Ugh, binary in JSON. This is one reason why I think raw "markers"
> shouldn't
> be exposed.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to