ZeroDivisionError: float division by zero when attempting to use 'run' on a specific release

[carlosparadis]

@Ext3h

Using the following config file:

project: storm
repo: storm # Relative to git-dir as specified on the command line
description: Apache Storm

revisions: ["0.9.0",
"0.9.0.1","v0.10.0",
"v0.9.1-incubating","v0.9.1.0-incubating","v0.9.2-incubating","v0.9.2-incubating-security",
"v0.9.3","v0.9.4","v0.9.5","v0.9.6","v1.0.0"]

rcs: ["0.9.0-rc1","0.9.0-rc2","0.9.0-rc3","v0.9.3-rc1","","","","","","","",""]


tagging: proximity

On apache storm repo, I am getting the following error:

vagrant@precise64:~/projects/storm$ codeface run -c /vagrant/codeface.conf -p storm.conf results/ git-repo/
2016-04-17 01:28:16 [codeface.project] MainProcess INFO: => Setting up project 'storm'
2016-04-17 01:28:16 [codeface.dbmanager] MainProcess ERROR: Release number 3 changed tag from v0.10.0-beta to v0.9.1-incubating. Recreating project.
2016-04-17 01:28:16 [codeface.dbmanager] MainProcess WARNING: Deleting and re-creating project storm/proximity.
2016-04-17 01:28:17 [codeface.dbmanager] MainProcess INFO: Adding 12 new releases...
2016-04-17 01:28:18 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0..0.9.0.1: Analysing commits...
Pass 1/2: 100% |###################################################################################################################################################################################| Time: 0:00:00
2016-04-17 01:28:18 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0..0.9.0.1: Commit analysis done.
2016-04-17 01:28:18 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0..0.9.0.1: Detecting clusters...
2016-04-17 01:28:32 [codeface.R.cluster.persons] INFO: Adjacency matrix empty, exiting cluster analysis
[1] 1
2016-04-17 01:28:32 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0..0.9.0.1: Detecting clusters done.
2016-04-17 01:28:32 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0..0.9.0.1: Generating reports...
2016-04-17 01:28:32 [codeface.util] MainProcess INFO:   -> Analysing revision range 0.9.0..0.9.0.1: Generating Reports...
2016-04-17 01:28:33 [codeface.util] MainProcess WARNING: Command 'lualatex -interaction=nonstopmode /home/vagrant/projects/storm/results/storm/proximity/0.9.0-0.9.0.1/report-0.9.0_0.9.0.1.tex' failed with exit code 1. Ignored.
2016-04-17 01:28:33 [codeface.util] MainProcess WARNING: Could not copy report PDF (missing input data?)
2016-04-17 01:28:33 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0..0.9.0.1: Report generation done.
2016-04-17 01:28:33 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0.1..v0.10.0: Analysing commits...
Blame Analysis: 100% |#############################################################################################################################################################################| Time: 0:07:59
Pass 1/2: 100% |###################################################################################################################################################################################| Time: 0:02:18
2016-04-17 01:39:51 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0.1..v0.10.0: Commit analysis done.
2016-04-17 01:39:51 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0.1..v0.10.0: Detecting clusters...
NULL
2016-04-17 01:40:28 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0.1..v0.10.0: Detecting clusters done.
2016-04-17 01:40:28 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0.1..v0.10.0: Generating reports...
2016-04-17 01:40:28 [codeface.util] MainProcess INFO:   -> Analysing revision range 0.9.0.1..v0.10.0: Generating Reports...
2016-04-17 01:40:31 [codeface.util] MainProcess INFO:   -> Revision range 0.9.0.1..v0.10.0: Report generation done.
2016-04-17 01:40:31 [codeface.util] MainProcess INFO:   -> Revision range v0.10.0..v0.9.1-incubating: Analysing commits...
Traceback (most recent call last):
  File "/usr/local/bin/codeface", line 9, in <module>
    load_entry_point('codeface', 'console_scripts', 'codeface')()
  File "/vagrant/codeface/cli.py", line 202, in main
    return run(sys.argv)
  File "/vagrant/codeface/cli.py", line 198, in run
    return args.func(args)
  File "/vagrant/codeface/cli.py", line 117, in cmd_run
    args.profile_r, args.jobs, args.tagging, args.reuse_db)
  File "/vagrant/codeface/project.py", line 113, in project_analyse
    endmsg=prefix + "Commit analysis done."
  File "/vagrant/codeface/util.py", line 110, in add
    func(*args, **kwargs)
  File "/vagrant/codeface/cluster/cluster.py", line 1944, in doProjectAnalysis
    rc_range)
  File "/vagrant/codeface/cluster/cluster.py", line 1830, in performAnalysis
    link_type, range_by_date, rcranges)
  File "/vagrant/codeface/cluster/cluster.py", line 66, in createDB
    git.extractCommitData(link_type=link_type)
  File "/vagrant/codeface/VCS.py", line 1047, in extractCommitData
    maxval=len(self._commit_dict)).start()
  File "build/bdist.linux-x86_64/egg/progressbar/__init__.py", line 311, in start
  File "build/bdist.linux-x86_64/egg/progressbar/__init__.py", line 283, in update
  File "build/bdist.linux-x86_64/egg/progressbar/__init__.py", line 243, in _format_line
  File "build/bdist.linux-x86_64/egg/progressbar/__init__.py", line 223, in _format_widgets
  File "build/bdist.linux-x86_64/egg/progressbar/widgets.py", line 38, in format_updatable
  File "build/bdist.linux-x86_64/egg/progressbar/widgets.py", line 184, in update
  File "build/bdist.linux-x86_64/egg/progressbar/__init__.py", line 208, in percentage
ZeroDivisionError: float division by zero

The id service pane doesn't seem to throw anything weird:

info: inserting/updating user Steven Phung <stphung@gmail.com>
info: inserting/updating user Sam Ritchie <sritchie@twitter.com>
info: inserting/updating user Norbert Potocki <norbert.potocki@nort.pl>
info: inserting/updating user Bryan Shell <bryan.shell@orbitz.com>
info: inserting/updating user Edison Xu <xeseo2005@gmail.com>
info: inserting/updating user hs <peoplebike@gmail.com>
info: inserting/updating user Paul DelRe <pdelre@gmail.com>
info: inserting/updating user Jeroen van Dijk <jeroentjevandijk@gmail.com>
info: inserting/updating user ptgoetz <ptgoetz@gmail.com>

I've actually attempted to remove a few releases on the transition from 0.10... to the following but the same error keeps reoccurring. However, removing 0.10 does solve the problem. So you should be able to reproduce the error with just that.

Thought I would report this situation here since I am not sure why that specific tag leads to this.

On a small side note, the following warnings are constantly issued by luatex:

2016-04-17 02:02:30 [codeface.util] MainProcess WARNING: Command 'lualatex -interaction=nonstopmode /home/vagrant/projects/storm/results/storm/proximity/v0.9.4-v0.9.5/report-v0.9.4_v0.9.5.tex' failed with exit code 1. Ignored.
2016-04-17 02:02:30 [codeface.util] MainProcess WARNING: Could not copy report PDF (missing input data?)

[wolfgangmauerer]

Am 17/04/2016 um 12:27 schrieb Andreas Ringlstetter:

Unfortunately expected. Codeface currently can't handle projects which
are making heavy use of branches and merging. That will cause
miss-attribution of commits to wrong timeframes, resulting in all types
of bugs, including empty release ranges. In this case, the commits
contributing mainly to 0.10 have been miss-attributed to some other release.

we should catch empty release ranges anyway, and there are some checks
around the codebase. Need to look into why they seem to fail in this
case.

Unless you're explicitly interested in analysing specific release
ranges, you might either want to use time-base partitioning (by not
specifying releases/RCs at all), or omit labels for (seemingly, I don't
know the project in detail) minor releases or intermittent branches,
something along the lines of

"0.9.0", "v0.9.3", "v0.9.4", "v0.9.5", "v0.9.6", "v0.10.0", "v1.0.0"

Not sure if I placed v0.10.0 sensibly. It might also, for instance,
stem from a branch that was developed in parallel with 0.9.x and should
be omitted from the list.

A more robust partitioning scheme for reliably breaking the commit graph
into non-empty commit ranges is currently under development.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#48 (comment)

[limjcst]

When I analyze rails, I face the similar error. I use the tags gotten by command git tag, keeping the order, to create .conf file as below. v0.9.1 follows v0.14.4.

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

However, there is no reason to remove any of the tags.
The first error occurs around codeface/VCS.py line 1047. I make a few changes.

--- a/codeface/VCS.py
+++ b/codeface/VCS.py
@@ -1043,8 +1043,11 @@ class gitVCS (VCS):
         # from this.
         count = 0
         widgets = ['Pass 1/2: ', Percentage(), ' ', Bar(), ' ', ETA()]
-        pbar = ProgressBar(widgets=widgets,
+        try:
+            pbar = ProgressBar(widgets=widgets,
                            maxval=len(self._commit_dict)).start()
+        except:
+            return self._commit_list_dict[subsys]

         for cmt in self._commit_dict.values():
             count += 1

The second error occurs around codeface/cluster/cluster.py line 1694. Then, the database operation, around line 1130, can't work without data. Below are the changes.

diff --git a/codeface/cluster/cluster.py b/codeface/cluster/cluster.py
index d363ff3..567bbf0 100755
--- a/codeface/cluster/cluster.py
+++ b/codeface/cluster/cluster.py
@@ -1126,9 +1126,12 @@ def writeCommitData2File(cmtlist, id_mgr, outdir, releaseRangeID, dbm, conf,
     # End for cmt

     # Perform bulk insert
-    dbm.doExecCommit("INSERT INTO commit (" + ", ".join(value_names) + ")" +
+    try:
+        dbm.doExecCommit("INSERT INTO commit (" + ", ".join(value_names) + ")" +
                      " VALUES (" + ", ".join("%s" for x in value_names) + ")",
                      cmt_db_rows)
+    except:
+        pass


 def writeSubsysPerAuthorData2File(id_mgr, outdir):
@@ -1691,7 +1694,10 @@ def computeCommitterAuthorLinks(cmtlist, id_mgr):
     #Process Bar Setup
     #----------------------------------
     widgets = ['Pass 2/2: ', Percentage(), ' ', Bar(), ' ', ETA()]
-    pbar = ProgressBar(widgets=widgets, maxval=len(cmtlist)).start()
+    try:
+        pbar = ProgressBar(widgets=widgets, maxval=len(cmtlist)).start()
+    except:
+        return

     for i in range(0, len(cmtlist)):

Finally, an error occurs around codeface/R/cluster/persons.r line 979.

diff --git a/codeface/R/cluster/persons.r b/codeface/R/cluster/persons.r
index 44b33fd..b49a51d 100755
--- a/codeface/R/cluster/persons.r
+++ b/codeface/R/cluster/persons.r
@@ -976,7 +976,16 @@ performAnalysis <- function(outdir, conf) {
   ################## Process the data #################
   logdevinfo("Reading files", logger="cluster.persons")
   mat.file <- paste(outdir, "/adjacencyMatrix.txt", sep="")
-  adjMatrix <- read.table(mat.file, sep="\t", header=TRUE)
+  fail <- tryCatch({
+    adjMatrix <- read.table(mat.file, sep="\t", header=TRUE)
+    F
+  }, error = function(e) {
+    T
+  })
+  if (fail) {
+    loginfo("Adjacency matrix empty, exiting cluster analysis", logger="cluster.persons")
+    return(1)
+  }
   adjMatrix.ids <- unlist(strsplit(readLines(mat.file, n=1), "\t"))

   colnames(adjMatrix) <- rownames(adjMatrix)

At the end, codeface tells me that it run completely.

[clhunsen]

When I analyze rails, I face the similar error. I use the tags gotten by command git tag, keeping the order, to create .conf file as below. v0.9.1 follows v0.14.4.

The tags given by git tag are ordered alphabetically, not by their creation date or even in the order as they appear in the commit history!
When you order the tags in a meaningful version-related manner, you will probably get a proper result out of Codeface. Notice also that beta versions (such as v4.2.0.beta1) need likely to appear before their cooresponding final version (in this example, this is v4.2.0).

[limjcst]

@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', '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

Change of .conf file brings new errors. I include some other empty check.

diff --git a/codeface/R/complexity.r b/codeface/R/complexity.r
index 9f2311e..8c20e28 100755
--- a/codeface/R/complexity.r
+++ b/codeface/R/complexity.r
@@ -201,6 +201,7 @@ do.complexity.analysis <- function(conf) {
       logdevinfo(str_c("Analysing sample ", i, "\n"), logger="complexity")
       commit.hash <- commits.list[[i, "commitHash"]]
       commit.date <- commits.list[[i, "commitDate"]]
+      if (is.na(commit.hash)) return(NULL)

       archive.file <- tempfile() # tarball from "git archive"
       results.file <- tempfile() # understand database

diff --git a/codeface/R/analyse_ts.r b/codeface/R/analyse_ts.r
index 0025ce5..c8e25ac 100755
--- a/codeface/R/analyse_ts.r
+++ b/codeface/R/analyse_ts.r
@@ -85,13 +85,13 @@ compute.next.timestamp <- function(time, last.time) {
 make.index.unique <- function(dat, subset) {
   dat$commitDate <- ymd_hms(dat$commitDate, quiet=TRUE)
   last.timestamp <- min(dat$commitDate) - dseconds(1)
-
-  for (i in 1:length(dat$commitDate)) {
-    dat$commitDate[[i]] <- compute.next.timestamp(dat$commitDate[[i]],
-                                                  last.timestamp)
-    last.timestamp <- dat$commitDate[[i]]
+  if (length(dat$commitDate) > 0) {
+    for (i in 1:length(dat$commitDate)) {
+      dat$commitDate[[i]] <- compute.next.timestamp(dat$commitDate[[i]],
+                                                    last.timestamp)
+      last.timestamp <- dat$commitDate[[i]]
+    }
   }
-
   return(dat)
 }

@@ -109,11 +109,14 @@ gen.full.ts <- function(conf) {
   if (dim(boundaries)[1] != length(ts)) {
     stop("Internal error: Release boundaries don't match ts list length")
   }
-
   for (i in 1:length(ts)) {
     ts[[i]]$ChangedLines <- ts[[i]]$AddedLines + ts[[i]]$DeletedLines
-    full.series[[i]] <- na.omit(xts(ts[[i]]$ChangedLines,
-                                    order.by=ts[[i]]$commitDate))
+    if (length(ts[[i]]$ChangedLines) > 0) {
+      full.series[[i]] <- na.omit(xts(ts[[i]]$ChangedLines,
+                                      order.by=ts[[i]]$commitDate))
+    } else {
+      full.series[[i]] <- na.omit(xts())
+    }
     full.series[[i]] <- trim.series(full.series[[i]], boundaries$date.start[i],
                                     boundaries$date.end[i])
   }

However, Codeface's shiny-server website isn't satisfying.

[wolfgangmauerer]

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
#48 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbE1_cVjcWTw0QsEU7Wkit7qxGi2EMgks5qV0blgaJpZM4IJELh.