We have struggled a bit with the merging of BNF code during the last couple of weeks, indication the current merge process is to cumbersome. we talked about this at the NetarchiveSuite workshop in Wien, where listed some solutions to our merge/branch challenges. here is a recap:
- It should be the branch responsible, who takes care of merging to/from non-trunk branches. This means that BNF is responsible for merging to trunk, and pulling changes from trunk to the BNF branch.
- Merge should be done frequently: The longer it takes before changes are updates between branches, the more difficult it will be to make a consistent merge.
- Update to newer Subversion: The currently used GForge Subversion 1.4 is very weak when it comes to branching and merging. The currently 1.6 has much better support for these features. Switching to the project to be SBForge hosted will fix this.
- Public and Continuous regression testing: The current Hudson integration server could catch a lot of the merge problems, but is currently embedded by:
- The server is not accessible from outside of SB and KB, which prevents BNF from using the information provided here. This problem would be solved by a move to SBForge
- We do not have a consistent regression test. This is both because we lack a suite of passing tests, and because the maintenance of the suite of regression test is to cumbersome. These problems could be solved by moving to a newer test framework, Junit4 or preferable TestNG, see Try out TestNG.
- Switch to a DVCS: Subversion is a Centralized Version Control System, where branch and merge functionality is an add-on. If we find that the merge functionality in the current svn is inadequate, we could consider migrating to a Decentral Version Control System (DVCS), which have branch/merge functionality as part of their core capabilities. We current use GIT here at SB, and the SBForge platform will properly provide a GIT repository.