archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <joa...@erdfelt.com>
Subject Monster Commit Breakdown - svn commit: r583412 [1/8]
Date Wed, 10 Oct 2007 19:25:01 GMT
This is an attempt to breakdown the monster commit to help people not 
fear it.

(Disclaimer: The views / opinions / rants herein are from a mad swede,
             myself, and do not reflect the views of the other devs
             and commitors in archiva.  Do not take the statements made
             within this email as canon of how things operate within
             archiva.  I have been merely asked to explain the monster
             commit as it is out of form and considered harmful to
             the project.)

  Was what I did wrong?  Probably.
  Was there a more appropriate way?  Probably.
  Was this a surprise commit?  No.
  Did this destablize the codebase?  No.
  Was the size of this commit excessive?  No. (1)
  Could I have split up this into different commits?  Probably. (2)
  Why did I do this?  Time. (3)
  Will I change?  Damn straight!

Technical Breakdown of commit:

  Label                                  Size  : Self : Overall
 ----------------------------------------------:------:--------

Totals (overall):
  Change Blocks .......................... 362 :      :    
  Property Changes ........................ 96 :      :    
  Count Entries (Total) .................. 131 :      :    
  Count Entries Added ..................... 32 :  24% :    
  Count Entries Removed ................... 11 :   8% :    
  Count Entries Modified .................. 87 :  66% :    
  Count Entries Property Change Only ....... 1 :   1% :    
  Lines (Total) ........................ 19225 :      :    
  Lines of Diff Overhead ................ 3994 :  21% :    
  Lines Added (Total) .................. 13126 :  68% :    
  Lines Added from New Entries ......... 11519 :  60% :    
  Lines Added from Modified Entries ..... 1607 :   8% :    
  Lines Removed (Total) ................. 2105 :  11% :    
  Lines Removed from Deleted Entries ..... 754 :   4% :    
  Lines Removed from Modified Entries ... 1351 :   7% :    
  Lines Modified Delta (Added - Removed) . 256 :      :    
  Lines of Comment Changes .............. 1716 :   9% :    

Totals (src/main):
  Change Blocks .......................... 156 :      :  43%
  Property Changes ........................ 54 :      :  56%
  Count Entries (Total) ................... 62 :      :  47%
  Count Entries Added ..................... 18 :  29% :  14%
  Count Entries Removed .................... 3 :   5% :   2%
  Count Entries Modified .................. 41 :  66% :  31%
  Count Entries Property Change Only ....... 0 :   0% :   0%
  Lines (Total) ......................... 6680 :      :  35%
  Lines of Diff Overhead ................ 1818 :  27% :   9%
  Lines Added (Total) ................... 3815 :  57% :  20%
  Lines Added from New Entries .......... 2884 :  43% :  15%
  Lines Added from Modified Entries ...... 931 :  14% :   5%
  Lines Removed (Total) ................. 1047 :  16% :   5%
  Lines Removed from Deleted Entries ..... 210 :   3% :   1%
  Lines Removed from Modified Entries .... 837 :  13% :   4%
  Lines Modified Delta (Added - Removed) .. 94 :      :    
  Lines of Comment Changes .............. 1015 :  15% :   5%

Totals (src/test):
  Change Blocks .......................... 206 :      :  57%
  Property Changes ........................ 42 :      :  44%
  Count Entries (Total) ................... 69 :      :  53%
  Count Entries Added ..................... 14 :  20% :  11%
  Count Entries Removed .................... 8 :  12% :   6%
  Count Entries Modified .................. 46 :  67% :  35%
  Count Entries Property Change Only ....... 1 :   1% :   1%
  Lines (Total) ........................ 12545 :      :  65%
  Lines of Diff Overhead ................ 2176 :  17% :  11%
  Lines Added (Total) ................... 9311 :  74% :  48%
  Lines Added from New Entries .......... 8635 :  69% :  45%
  Lines Added from Modified Entries ...... 676 :   5% :   4%
  Lines Removed (Total) ................. 1058 :   8% :   6%
  Lines Removed from Deleted Entries ..... 544 :   4% :   3%
  Lines Removed from Modified Entries .... 514 :   4% :   3%
  Lines Modified Delta (Added - Removed) . 162 :      :    
  Lines of Comment Changes ............... 701 :   6% :   4%

  (The code for this output is available on my personal svn space)

Interesting Features of the Technical Breakdown:

  * There was only a delta of 256 lines changed in existing files.
  * There is an almost 2::1 ratio of test to main code.
  * 20% of the diff is overhead.
  * 9% of the diff is comment changes. (thats alot)
  * The majority of the new files (29%) arrived into src/main directories.
  * The majority of the diff (57%) occurs in the src/test directories.
  * The majority of new content/lines (74%) arrived into src/test 
directories.

  (1) I submit that this is not an excessive commit, as seen from the
      facts above.

The Reasons For It:

  First: THIS IS NOT A MAVEN 1 LEGACY ONLY PROBLEM as some people have
         suggested.  The way layouts were used within archiva prior to
         this commit made the entire core unreliable, inconsistent, and
         subject to failure in real world scenarios.

  As we get more and more users of Archiva for their day to day projects,
  we see more and more examples of legitimate usage of Archiva where the
  most basic functions fail due to a one layout assumption or another.

  The jist of the commit is to eliminate the possibility of failure by
  removing the ability to take shortcuts in the code.

  There was also plenty of uncoding done here to join together the
  various implementations of finding versions, or related files,
  or updating metadata.

  (2) I could have split this commit up into separate pieces, but decided
  that getting this code into place was more important that spending the
  next several days carefully crafting the optimum separation of commits
  to perform that wouldn't break the build, or have a dependency on another
  commit coming up.  This was my decision, I was not coerced into it, I
  weighed the options (3) and felt that getting a version 1.0 out sooner
  rather than later was more important. 

  I would love to see Archiva 1.0 final out before ApacheCon US
  (starting on November 10th, 2007)

  This code is a bug fix for current open and assigned jiras, it is not
  a rearchitecting, or work against future issues, or even an attempt at
  code perfection.

  Archiva is a web application, and as such, will have a different way
  of handling changes to the codebase, it is not subject to the the same
  stringent commit and change controls in place for maven, or java libs,
  or components that are either released, shared, or in common use across
  many users or other applications.  This is the best time to make these
  kind of changes, before the release, before the web services.

  I acknowledge that I could have branched this, which given the flak i'm
  getting for this commit, I probably should have.  But I stand by this
  change as a means to get the product stable in a faster fashion.

  I apologize for scaring the crap out of the other devs.
  I apologize for for not making a branch first.
  I apologize for not splitting up the commit.
  I apologize for stomping across other peoples active work.

  In the future I promise to be more clear about the scope of changes
  that need to be done.

  I promise to better manage my commit sizes and scope in the future.

  Hopefully, this has addressed any concerns about this monster commit.

  If not, please, by all means, SAY SOMETHING. ;-)

  In the end, I'm sure every developer and commitor for Archiva will
  appreciate this change for what it is.

-- 
- Joakim Erdfelt
  joakim@erdfelt.com
  Open Source Software (OSS) Developer


Mime
View raw message