archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maria Odea Ching <och...@exist.com>
Subject Re: Monster Commit Breakdown - svn commit: r583412 [1/8]
Date Sat, 13 Oct 2007 05:15:06 GMT
Thanks for this email Joakim :) It helped people to better understand 
all the recent changes in the codebase. I admit I have also panicked 
when I saw some of the classes I was using in my codes (that I still 
haven't committed yet) were removed, but after reading the past threads 
plus this email I think I know (at least) where to find or what to use 
in place for those classes.

Anyway, as what has already been mentioned by Brett and Wendy.. it 
would've been better to have the changes committed piece by piece 
instead of a giant commit as a lot of other developers/contributors 
would get affected especially since we're nearing the 1.0 release. I 
admit, I am also guilty of doing this at times and maybe we could all 
learn from this so-called 'monster commit panic' to practice committing 
our changes piece by piece :-)

-Deng

Joakim Erdfelt wrote:
> 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.
>


Mime
View raw message