SCM Logging

[Frank Becker]

Hi,

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
you prefer?

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.)

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.

Thanks,

Frank

--
Frank Becker <f...@alien8.de> (jabber|mail) | http://twitter.com/41i3n8
GnuPG: 0xADC29ECD | F01B 5E9C 1D09 981B 5B40 50D3 C80F 7459 ADC2 9ECD

[Stefan Marr]

Hi Frank:

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

It is basically a mixture of 1 and 2, a best effort search.

Not nice, but works 'good enough for me'.

For me, supporting 1. is very important to be able to identify where
the regression comes from.

Best regards
Stefan

[Frank Becker]

On 8/15/11 3:37 PM, Stefan Marr wrote:

Hi Stefan,

> 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).

[Miquel Torres]

Sounds good!

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>: