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

[Paolo Giarrusso]

Hi Miquel!

> I would gladly hear other ideas.
Here are my two cents!

On Fri, Jan 21, 2011 at 08:49, Miquel Torres <tobami at googlemail.com> wrote:
> So one idea would be:
> - Every revision has a branch associated to it (a problem though is
> that subversion has the same revision number for all branches, while
> mercurial and git not)
This suggests (to me) that a revision would be associated to a
specific branch, but then I don't get expressions like "all the
branches for a revision". Maybe you mean that you would replace
revisions with pairs (Revision, Branch)?
[...]
> - There are problems with this approach. In the Changes view, when you
> select a revision that doesn't have results for the currently selected
> branch, nothing would be displayed.

You're referring to an SVN context, right? Otherwise I can't make sense of it.

I guess you can use, on other branches, the "closest" revision
available, after defining a linear order on revisions across branches.
You have that order in SVN; since you don't have that in Git, why
don't you just use the _date_ of a revision as the ordering key?
[For the data structures to implement this, I've seen even seen
interfaces to tree-based dictionaries allowing navigating to the
key-predecessor and key-successor, which might be especially handy
here (such as NavigableMap in Java, dunno about Python).]
Of course, that's suitable just as default, so you need to be able to
navigate between revisions independently for each branch.

Please note that with complex merge histories, using the date does not
necessarily make sense - so that at least Git tools provide many
linearization algorithms. The problem is that a commit might be made
on a certain date in some repository, but be merged on mainline much
later, especially when many developers are not committers themselves;
one solution is to consider only revisions which were committed
directly on the branch or merged shortly after.
I also would believe this use case does not appear for PyPy.
See help about git log --topo-order and --date-order (such docs used
to be more complete, though).

> You would need to blindly search
> for your results. An option is to always display all branches for a
> revision, but sometimes a revision will contain results for a branch,
> sometimes for others.
Outside of the SVN context, I'm not sure I get what you mean here,
because revisions in different branches are not necessarily
comparable.
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/