{"id":398,"date":"2007-01-27T19:23:07","date_gmt":"2007-01-28T01:23:07","guid":{"rendered":"http:\/\/www.mooreds.com\/wordpress\/archives\/000398"},"modified":"2007-01-30T16:29:50","modified_gmt":"2007-01-30T22:29:50","slug":"molhadoref-a-refactoring-aware-version-control-system","status":"publish","type":"post","link":"https:\/\/www.mooreds.com\/wordpress\/archives\/398","title":{"rendered":"MolhadoRef: A refactoring-aware version control system"},"content":{"rendered":"<p>This past Thursday, I went to one of the <a href=\"http:\/\/www.cs.colorado.edu\/events\/colloquia\/current\/\">CU Comp Sci   Colloquia<\/a>.  The speaker was <a href=\"https:\/\/netfiles.uiuc.edu\/dig\/www\/\">Danny Dig<\/a>, and he discussed <a href=\"http:\/\/www.cs.colorado.edu\/events\/colloquia\/current\/dig.html\">Refactoring-Aware Software Merging and Version   Control for Object-Oriented Programs<\/a>, in particular, <a href=\"https:\/\/netfiles.uiuc.edu\/dig\/MolhadoRef\/molhadoref.html\">MolhadoRef<\/a>.  Mr Dig billed this several times as   the first refactoring aware source control system &#8216;that we are aware of&#8217;.<\/p>\n<p>Being <a href=\"http:\/\/www.mooreds.com\/wordpress\/archives\/000334\">relatively new to IDEs in general and Eclipse in   particular<\/a>, I find that the automatic refactoring is one of the largest productivity enhancements that I&#8217;ve   discovered.  The ability to almost effortlessly change a variable name to more accurately reflect its purpose, and   to know that such a change will propagate everywhere it is used, lets you update variable names more often.  I was   recently editing a piece of PHP code and one of the variables had changed slightly in purpose.  I could have done a   search and replace, but I wouldn&#8217;t be positive that the changes hadn&#8217;t broken something subtle.  With Eclipse,   there&#8217;s no such hesitation.<\/p>\n<p>This is almost worth the cost of having to use the mouse and not being able to use vi keystrokes (at least, without   the <a href=\"http:\/\/www.satokar.com\/viplugin\/index.php\">vi plugin<\/a>).  But when you throw in the other   refactorings, including move method and rename method, well, refactoring becomes invaluable.<\/p>\n<p>What follows are my notes from the talk.<\/p>\n<p>Mr Dig discussed how refactoring is becoming more prevalent in todays development environments, and how this is   challenging text based version control systems such as CVS and SVN.  The main issues are that refactoring causes   global changes, while version control systems excel at tracking local changes.  In addition, refactoring impacts   program elements, while version control systems focus on files.  In short, refactorings are more likely than normal   edits to create conflicts and\/or merge errors&#8211;due to refactoring tools, changes are regularly no longer limited to   files.<\/p>\n<p>In addition, when you move members between classes, you can lose version history&#8211;the only connection back to the   original location is a commit comment, which is neither dependable nor robust.<\/p>\n<p>MolhadoRef aims to change this, by making the version control system become refactoring aware.  Currently MolhadoRef   exists in &#8216;research project&#8217; form as an Eclipse plugin, and is part of Mr Dig&#8217;s PhD thesis work.  (By &#8216;research   form&#8217;, I think he means not ready for prime time.  For example, in his demo, when you checked changes in, there was   no support for a commit message.)  There are plans to release it as an open source project, but it is currently not   so available.   MolhadoRef is based on <a href=\"http:\/\/home.eng.iastate.edu\/%7Etien\/molhado\/index.html\">Molhado<\/a>,   which is an SCM system with support for OO software, on the backend, and Eclipse and a refactoring engine on the   front end.<\/p>\n<p>Basically, MolhadoRef can handle API level merging, where &#8216;API level&#8217; means any member declarations.  It also   supports normal text edits in the same manner as CVS or SVN.  It also tracks compile time as well as runtime merge   conflicts.<\/p>\n<p>On checkin, it follows the following algorithm:<\/p>\n<ol>\n<li>Detect API change operations, using a 3 way comparison.  They are also tracked with tools such as <a href=\"http:\/\/www-plan.cs.colorado.edu\/henkel\/catchup\/\">Catchup<\/a> or <a href=\"https:\/\/netfiles.uiuc.edu\/dig\/RefactoringCrawler\/\">RefactoringCrawler<\/a><\/li>\n<li>Detect and resolve conflicts.  It attempts to do so in an automated fashion, but sometimes requires user   input.<\/li>\n<li>Undo refactorings.  Sometimes this is not entirely possible, but if it fails, MolhadoRef is intelligent enough   to fall back to a text merge.<\/li>\n<li>Merge text changes.  This happens on a method level, not on a file level.<\/li>\n<li>Replay refactorings.  This can be hard, because you need to serialize what may have been two parallel series of   refactorings.  He went into some things I didn&#8217;t understand right here, including using graph theory to reorder the   refactoring, or making a refactoring into an enhanced refactoring (which not only changes code, but future   refactorings in the chain).<\/li>\n<\/ol>\n<p>Mr Dig conducted a case study and an experiment to prove the effectiveness of MolhadoRef.  In the case study, he and   a partner developed MolhadoRef separately for 3 weeks, and then merged the changes using both MolhadoRef and CVS.    With 1267 lines of changed code, CVS had 36 conflicts, 41 compile errors, 7 runtime errors (determined by unit test   coverage), and it took 105 minutes (including human time) to merge the two trees.  In contrast, MolhadoRef had 1   conflict, 0 compile and runtime errors, and it took 1 minute to merge.  Pretty impressive.<\/p>\n<p>The experiment was to split 10 students (fairly experienced with Eclipse and java) into two groups.  Each group had   a common task.  At the end, the changes made by each person in the first group were merged with the changes made by   each person in the second group, producing 25 merge sessions.  Using these episodes, using MolhadoRef led to 3.6   times fewer conflicts, 11.6 times fewer compiler errors, and 1.5 fewer runtime errors.  In addition, the time to   merge was 3.5 times faster with MolhadoRef.<\/p>\n<p>The larger picture that Mr Dig is pursuing is to perform automated upgrades of component based applications (<a href=\"http:\/\/www.ecoop.org\/phdoos\/ecoop2006ds\/ds\/dig.pdf\">pdf<\/a>).  If you&#8217;ve ever upgraded from one version of a   java web framework to another, you&#8217;ll know how painful it can be, especially if the API has changed.  According to   Mr Dig, 80% of the API changes in 5 projects he&#8217;s examined so far (4 open source, 1 proprietary) were due to   refactorings.  He told us why MolhadoRef fits into this picture, but I didn&#8217;t note it.  Bummer.<\/p>\n<p>He did say that both Microsoft and IBM were interested in his work.  He also mentioned, I think, that Eclipse has   already accepted some of his refactoring code.<\/p>\n<p>\/Notes<\/p>\n<p>What does that mean for us developers who don&#8217;t use build version control systems?  well, not much right now, but if   some of the bigger providers start to use this, it means that bigger, longer lived projects can be better managed;   that code history won&#8217;t be lost as often, and that merge conflicts will decrease in severity and number.  I for one   can&#8217;t wait for that day.<\/p>\n<p>[tags]refactoring, version control systems[\/tags]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This past Thursday, I went to one of the CU Comp Sci Colloquia. The speaker was Danny Dig, and he discussed Refactoring-Aware Software Merging and Version Control for Object-Oriented Programs, [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,9,5,6],"tags":[],"class_list":["post-398","post","type-post","status-publish","format-standard","hentry","category-cu-colloquia","category-ides","category-java","category-programming"],"_links":{"self":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/398","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/comments?post=398"}],"version-history":[{"count":0,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/398\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/media?parent=398"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/categories?post=398"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/tags?post=398"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}