My understanding of code churn (http://msdn2.microsoft.com/en-us/library/ms244698.aspx) is that it is calculated by [Lines Added] + [Lines Deleted] + [Lines Modified].
So having 3 or 4 failed migrations that needed to be redone ends up with a report like this:
| Alias |
Lines Added |
Lines Deleted |
Lines Modified |
Total Churn |
Total Lines |
Code Churn Count |
| A |
|
|
|
|
|
|
| |
194750 |
116953 |
36298 |
348001 |
77797 |
6147 |
| B |
|
|
|
|
|
|
| |
1667 |
603 |
725 |
2995 |
1064 |
76 |
| THIS IS MY ENTRY |
|
|
|
|
|
|
| |
516955 |
431007 |
102022 |
1049984 |
85948 |
18029 |
| C |
|
|
|
|
|
|
| |
28995 |
8318 |
8792 |
46105 |
20677 |
906 |
| D |
|
|
|
|
|
|
| |
56574 |
7122 |
5955 |
69651 |
49452 |
1525 |
| E |
|
|
|
|
|
|
| |
10742 |
3601 |
5650 |
19993 |
7141 |
507 |
The problem is that this particular solution doesn't even contain 200,000 lines of code but because of the 1st few failed migrations the reports will now show my total churn of over 1,000,000 lines.
The calculation is accurate but isn't what we want. There really should be a way to recover from this kind of scenario w/o having to completely remove the whole team project. I'm thinking that some sort of administrator level permanent removal tool or some way to set a folder to not count against statistics in the cube. BTW - the report above is a custom report that is simply checked in alias by the 6 variables listed above.
|