[codeface] Re: [siemens/codeface] ZeroDivisionError: float division by zero when attempting to use 'run' on a specific release (#48)

From: Wolfgang Mauerer <wm@xxxxxxxxxxxxxxxx>
To: siemens/codeface <reply+0016c4d7a70d32ac63f8604e6b8b953b2e30d751138da17f92cf0000000113a062e592a169ce08e03123@xxxxxxxxxxxxxxxx>, siemens/codeface <codeface@xxxxxxxxxxxxxxxxxx>
Date: Thu, 28 Jul 2016 00:25:18 +0200

Am 15/07/2016 um 10:37 schrieb limjcst:

@clhunsen <https://github.com/clhunsen> You are right. I find another
command instead.

|git for-each-ref --format='%(*committerdate:raw)%(committerdate:raw)
%(refname) %(*objectname) %(objectname)' refs/tags | sort -n | awk
'{split($3, temp, "refs/tags/"); print temp[2]; }' |

v2.0.0 and v2.0.1 are the same. My change jumps over such Revision range
to make Codeface going on.
Below is the .conf file created.

|project: root@rails description: repo: . revisions: ['v0.9.1', 'v0.9.2',
'v0.9.3', 'v0.9.4', 'v0.9.4.1', 'v0.9.5', 'v0.10.0', 'v0.10.1',
'v0.11.0', 'v0.11.1', 'v0.12.0', 'v0.13.0', 'v0.13.1', 'v0.14.1',
'v0.14.2', 'v0.14.3', 'v0.14.4', 'v1.0.0', 'v1.1.0', 'v1.1.1', 'v1.1.2',
'v1.1.3', 'v1.1.4', 'v1.1.5', 'v1.1.6', 'v1.2.0', 'v1.2.1', 'v1.2.2',
'v1.2.3', 'v2.0.0_PR', 'v1.2.4', 'v1.2.5', 'v1.2.6', 'v2.0.0', 'v2.0.1',

thanks for sharing your configuration -- the problem with v2.0.0 and
v2.0.1 that you mentioned is still present here, though. Just to make
sure, a working, but fairly dated tag-based configuration is in
conf/rails.conf. This might serve as a good starting point that can
be stepwise extended to identify problematic ranges.

Without knowing the project in-depth, ruby@rails does not seem to attach
a particular structure to cutting releases. However, a crucial
assumption of a tag-based analysis is that the time of a release carries
some information and is not purely random.

For this project, I think that using a time range based analysis that
partitions the project into time windows of three months might be more
suited; you can activate this mode by specifying an empty list of tags.
Could you try this mode instead? It should not crash Codeface (if it
does, it's a real bug that needs to be fixed ;)), albeit the
interpretation of the results will differ (in particular when time
series are compared).

It would be very useful to have Codeface run a pre-check on a given
commit list to ensure that all ranges are correctly specified and
non-empty to avoid the types of problems you describe, but so far
no one has stepped forward to implement such measures.

'v2.0.2', 'v2.0.3', 'v2.1.0', 'v2.0.4', 'v2.1.1', 'v2.0.5', 'v2.1.2',
'v2.2.0', 'v2.2.1', 'v2.2.2', 'v2.3.0', 'v2.3.1', 'v2.3.2', 'v2.3.2.1',
'v2.3.3', 'v2.3.3.1', 'v2.3.4', 'v2.2.3', 'v2.3.5', 'v3.0.0.beta1',
'v3.0.0.beta.2', 'v3.0.0.beta2', 'v3.0.0.beta.3', 'v3.0.0.beta3',
'v2.3.6', 'v2.3.7', 'v2.3.8', 'v3.0.0.beta4', 'v3.0.0', 'v2.3.9.pre',
'v2.3.9', 'v2.3.10', 'v3.0.1', 'v3.0.2', 'v3.0.3', 'v3.0.4', 'v2.3.11',
'v3.0.5', 'v3.0.6', 'v3.0.7', 'v3.1.0.beta1', 'v2.3.12', 'v3.0.8',
'v3.0.9', 'v2.3.13', 'v2.3.14', 'v3.0.10', 'list', 'v3.1.0', 'v3.1.1',
'v3.0.11', 'v3.1.2', 'v3.1.3', 'v3.2.0', 'v3.2.1', 'v3.2.2', 'v3.1.4',
'v3.0.12', 'v3.2.3', 'v3.2.4', 'v3.1.5', 'v3.0.13', 'v3.2.5', 'v3.2.6',
'v3.1.6', 'v3.0.14', 'v3.0.15', 'v3.2.7', 'v3.1.7', 'v3.0.16',
'v3.0.17', 'v3.1.8', 'v3.2.8', 'v3.2.9', 'v3.2.10', 'v3.1.9', 'v3.0.18',
'v3.2.11', 'v3.1.10', 'v3.0.19', 'v2.3.15', 'v2.3.16', 'v3.0.20',
'v3.2.12', 'v3.1.11', 'v2.3.17', 'v4.0.0.beta1', 'v3.1.12', 'v3.2.13',
'v2.3.18', 'v4.0.0', 'v3.2.14', 'v3.2.15', 'v4.0.1', 'v3.2.16',
'v4.0.2', 'v4.1.0.beta1', 'v3.2.17', 'v4.0.3', 'v4.1.0.beta2', 'v4.0.4',
'v4.1.0', 'v4.1.1', 'v4.0.5', 'v3.2.18', 'v4.0.6', 'v4.1.2', 'v3.2.19',
'v4.0.7', 'v4.1.3', 'v4.0.8', 'v4.1.4', 'v4.0.9', 'v4.1.5',
'v4.2.0.beta1', 'v4.1.6', 'v4.0.10', 'v4.2.0.beta2', 'v3.2.20',
'v4.0.11', 'v4.1.7', 'v4.2.0.beta3', 'v4.2.0.beta4', 'v4.1.8',
'v4.0.12', 'v3.2.21', 'v4.1.7.1', 'v4.0.11.1', 'v4.2.0', 'v4.0.13',
'v4.1.9', 'v4.2.1', 'v4.1.10', 'v4.1.11', 'v4.2.2', 'v3.2.22',
'v4.1.12', 'v4.2.3', 'v4.1.13', 'v4.2.4', 'v4.2.5', 'v4.1.14',
'v5.0.0.beta1', 'v5.0.0.beta1.1', 'v4.2.5.1', 'v4.1.14.1', 'v3.2.22.1',
'v5.0.0.beta2', 'v5.0.0.beta3', 'v3.2.22.2', 'v4.2.5.2', 'v4.1.14.2',
'v4.2.6', 'v4.1.15', 'v5.0.0.beta4', 'v5.0.0', ] rcs: ['v0.9.1', '',
'','','','','','','','','','','','','','','','','v1.1.0_RC1',
'','','','','','','v1.2.0_RC1', '','','','','','','v2.0.0_RC1',
'v2.0.0_RC2', '','','v2.1.0_RC1',
'','','','','','','','','','','','','','','','','','','','','','','','','','','v3.0.0_RC',
'','','','','','','v3.0.4.rc1', '','v3.0.5.rc1', 'v3.0.6.rc1',
'v3.0.7.rc1', '','v3.1.0.rc1', 'v3.1.0.rc2', 'v3.0.9.rc1', 'v3.1.0.rc5',
'','','v3.1.0.rc6', 'v3.1.0.rc7', 'v3.1.1.rc1', 'v3.1.2.rc1',
'','','v3.2.0.rc1', '','v3.2.2.rc1', '','','v3.2.3.rc1', 'v3.0.13.rc1',
'','','','','','','','v3.2.7.rc1', '','','v3.2.8.rc1',
'','','v3.2.9.rc1',
'','','','','','','','','','','','','','v3.2.13.rc1',
'','','v4.0.0.rc1', 'v3.2.14.rc1', 'v3.2.15.rc1', 'v4.0.1.rc1',
'','','','','','','v4.1.0.rc1', 'v4.1.0.rc2', '','','','v4.0.6.rc1',
'','','','','','','','','v4.0.10.rc1', 'v4.0.10.rc2',
'','','','','','','','','','','','','v4.2.0.rc1', 'v4.0.13.rc1',
'','v4.2.1.rc1', '','','','','v4.1.12.rc1', '','v4.1.13.rc1',
'','v4.1.14.rc1', '','','','','','','','','','','','v4.2.6.rc1',
'','','v5.0.0.rc1', ] tagging: committer2author |

It's interesting that v3.2.22.1 appears after v4.1.14.1

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/siemens/codeface/issues/48#issuecomment-232894837>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABbE1_cVjcWTw0QsEU7Wkit7qxGi2EMgks5qV0blgaJpZM4IJELh>.

[codeface] Re: [siemens/codeface] ZeroDivisionError: float division by zero when attempting to use 'run' on a specific release (#48)

Other related posts: