Packagers: nightly builds?

[Gilles Moris]

On Wed January 28 2009 17:44:20 Benoit Boissinot wrote:
> > This seems like an extension that should be included in hgext/.
> > Feel like submitting it for inclusion?
> 
> I don't know how other feels, but maybe it could be available in the
> templating engine, so you could just do hg parents with the right
> template (btw maybe the "dirty" '+' from hg id could be exposed too).
> 

I would be more than happy to submit or to work on templating my extension.
The alternatives are:

1) inclusion of nearest in hgext: the faster solution, as the code is ready. You may want to review the style. I could get rid of the legacy code to support previous HG version and be more compliant to the current style. 

2) update the templating engine: I don't know that piece of code that much, but when I looked at it, it was pretty well designed to display one node at a time. Here I have 2 nodes: the given source cset, and the target node which correspond to the found tag.
Probably this extension is oversized as it stands now, we could just keep {nearesttags}, {nearesttags|first}, {nearesttags|all} and {nearesttagdistance}.
We also may want different templates for searching tags forward (the main reason I wrote this extension: in which version did this bug get fixed ?).

3) extending the hg id will be also challenging in term of API. We don't want to change the default output of hg id without arguments, don't we ? This could break existing scripts.
So probably the best would be adding an additional option like --nearest '%formats'. May be even another option to search nearest tag forward.
hg id should have a simple API though, otherwise we will pull away from the question this command tries to answer: what is that node ?


Solutions 2) and 3) does not cover the --match option of nearest. For 2), this could be covered once Brendan's patch to get arguments to the templates filters, and have a special filter for that.
Anyway, I am expecting some discussions about
a/ the API provided by 2) and 3)
b/ the implementation details of those APIs
And this is a good thing as this would be a new API to the core, and that we have to think twice. BTW, do we want 2), 3) or both ?

Since it may be difficult to make it before the feature freeze, I would propose 1) submission for inclusion in hgext in a first step (is there a process for that BTW).
Then try to get a consensus on how it should make it to the core. May be the crew has a better vision than me about that.

Regards.
Gilles.