On my current project, we release code often. As a result, we usually have at least one active branch along with the trunk. When bugs arise in production, we fix them in the branch and then merge them into the trunk. This constant merging was becoming a pain, so we automated it with a rake task that looks like:
desc 'merge changes from branch to trunk' task :'svn:merge_to_trunk' do if %x[svn info].include? "branches" puts "Merging changes into trunk. Don't forget to check these in." system "svn diff | patch -p0 -d /path/to/truck/checkout" end end
This task first checks to see if we are on the branch. If our checkout is from the trunk, it does nothing. Then, it does a “svn diff” and pipes that into patch, which applies the diff to the local working copy for the trunk.
We added this task as a dependency on our commit task, which we run in order to check in (see Ruby: rake commit). Once we check into the branch, we switch over to the trunk working copy and run “rake commit” again to check in the changes.
5 Responses to “Automatically merge changes from branch to trunk”
Sorry, the comment form is closed at this time.
Sounds like there is also a bigger problem as well. Out of curiosity how frequent do these merges occur? Perhaps there is an opportunity to build in checks into the development process to avoid this issue all together. In any case, I do like the approach you’ve taken to address the immediate pain point and I am sure I can apply it in the future.
Thanks for sharing!
We probably do about 15 merges in a two week period while we are in QA, and then fewer after that. What do you mean by checks into the development process?
What I meant by checks in the development process is both automated and manual (exploratory) testing of the implementation prior to even deploying to QA.
I can understand having to patch the code while it is being QA’d, however, whether 15 merges in a two week period is a lot depends on a variety of factors including the number of developers, the number of features being implemented, and the length of time spent coding prior to formal ‘QA’.
I prefer to work iteratively with at least one imbedded tester who works with the development team testing the features as they are being worked on. For now, my experiences here have only included “exploratory testing”:http://www.satisfice.com/articles/what_is_et.shtml.
I’m curious to explore automated acceptance tests (i.e., Fitnesse) further but I just haven’t been able to make it happen on the projects that I have been on thus far.
In any case, I look at any bugs that make it into production as an opportunity to re-evaluate the team’s development process in order to avoid bugs in the future. In my experience it is much cheaper and, more importantly, less painful, to catch things earlier rather than later.
How can you check if the trunk working? By automated tests?
Yes, we run the automated tests to verify the trunk is working before we check in.