[pypy-dev] New version of Codespeed (0.7) for speed.pypy.org

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Fri Jan 21 19:34:11 CET 2011

On 06:14 pm, anto.cuni at gmail.com wrote:
>On 21/01/11 08:49, Miquel Torres wrote:
>>Yes, branches are a pending item that has been requested a couple of 
>>times now.
>yes, I think most of the requests has been by me :)
>>The current solution is actually not to abuse an environment like you
>>say, but to create a new project for a branch. That way it gets
>>cleanly separated, and in a way branches are like different projects.
>>But it is of course not optimal. Technically it is very easy to come
>>up with several solutions (add a branch dimension, for example), but
>>interface-wise it is not easy to find something that doesn't clutter
>Uhm, I don't think that using a different project is a good idea. For
>branches, we are usually not much interested in the branch history, but 
>in the
>comparison with trunk (ideally, with trunk at the point we created the 
>or at the point of the last merge from trunk).
>As for visualize changes, I think that we don't need anything fancy, 
>example it would be already immensely useful to have the possibility of
>displaying the Changes page in a way that it compares the performances 
>of the
>branch against trunk.

How about a "Branches" checkbox (per project?  per executable?  per 
graph?  One of those maybe).  When it's checked, branch results within 
the revision horizon (last 10, 50, 200, etc) get plotted on the same 
graph as the trunk data is plotted.  Each branch could be a different 
color, perhaps (but would at least have hover info telling you what it 

This implies adding a branch column to the results table (or is it the 
revisions table?).

Maybe that's just the obvious way to do it and everyone else already 
thought of and discarded it already, though.

Actually, in general I'd like a way to plot more things on one graph. 
So maybe this is just a special case of that.


More information about the Pypy-dev mailing list