Currently, I'm trying to improve the code dealing with SCM a bit. First
thing is to limit the amount of SCM log entries shown in codespeed.
One of my use case is let's say the Linux kernel. Doing benchmarks over
one year means about 42k commits. Imagine http://host/changes. It will
take way to long to load them in this view.
OK, the obvious solution would be to limit the commit logs. What would
1) All commit logs between the last two results (reportet results for a
2) The last 15 commits. (The number made configureable in settings.py)
3) As it is today. (All commit logs from the 1st revision to the current
Some other idea?
BTW, the whole change log issue is a bit tricky since the history is not
linear. But that's a different story.
> On Aug 15, 3:23 pm, Frank Becker <f...@alien8.de> wrote:
>> 1) All commit logs between the last two results (reportet results for a
>> benchmark run)
>> 2) The last 15 commits. (The number made configureable in settings.py)
>> 3) As it is today. (All commit logs from the 1st revision to the current
>> shown one.)
> Have a look at the github backend (could use improvement) and my
> commit here: https://github.com/tobami/codespeed/commit/9538462fb810f3cb8e9c6e704399252a2035b48a
Wow, that was quick. Sure, github and git have a lot in common. :)
I will try that for git too. First I need a bit to cool my head down
from reading git man pages.
> For me, supporting 1. is very important to be able to identify where
> the regression comes from.
Sure, maybe the config option should be how many commits with results
backwards one wants to see (The ones in between included of course).
A "limit logs" checkbox, active by default (15 sounds good) would
cover both 1 and 2. A settings parameter would be worse, as it would
make it "hard coded" for the whole Codespeed instance.
2011/8/15 Frank Becker <f...@alien8.de>: