Fails to populate missing values when re-running build with more operators

[AustEcon]

This is a really awesome tool! Thanks!

I found a bug playing around...

To reproduce this bug:

1. Build e.g. last 10 commits
2. Then specify e.g.:
   $ wily build name_of_folder -n 15 -o raw (which will add on 5 more rows to the table but only loc)
3. Then you will see that:
   $ wily report name_of_folder
   will show Not found 'cyclomatic' Not found 'maintainability' and Not found 'halstead' (as expected)
4. But THEN, if you do:
   $ wily build name_of_folder -n 15 -o raw,maintainability which does nothing or
   $ wily build name_of_folder -n 20 -o raw,maintainability which correctly populates the next 5 rows of the table but does not identify the fact that there are missing values in previous rows that also need to be filled...

Seeing as though this script takes quite a while to run, I think it would be optimal if it behaved in a way such that it would recognise missing data and fill in the blanks before proceeding with new rows. What do you think?

Or am I not entering commands correctly?

[tonybaloney]

thanks @AustEcon

The build command doesn't compare the revisions, it considers them write-once-read-many.

This was design because running the index for any revision is time-consuming.

But, the index does store a list of metrics for each revision, so potentially it could compare that with the list of requested operators and re-index any revisions.

The report command should ignore revisions that have missing data values though, so I'm going to test the scenario you've explained