Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Merging and branching in Subversion 1.5

Upcoming release features automatic merge tracking -- finally!

By John Ferguson Smart, JavaWorld.com, 01/29/08

Page 3 of 4

Make some fixes

Now suppose we make some fixes to the production branch. This is done in the usual way, by correcting the source code and committing to the production branch. The following listing shows three successive modifications made and committed to the repository:

Listing 7. Three updates to the production branch

E:\tax-calculator-prod>svn commit -m "Corrected the tax rates"
Sending        tax-calculator\src\com\jpt\taxcalculator\domain\TaxCalculator.java
Transmitting file data .
Committed revision 23.
...

E:\tax-calculator-prod>svn commit -m "Updated the tax rate calculation"
Sending        tax-calculator\src\com\jpt\taxcalculator\domain\TaxCalculator.java
Transmitting file data .
Committed revision 24.
...

E:\tax-calculator-prod>svn commit -m "Updated the tax rate calculator module."
Sending        tax-calculator\src\com\jpt\taxcalculator\domain\TaxRate.java
Transmitting file data .
Committed revision 25.

Integrate the changes

Eventually, we want to integrate our changes back into the normal development branch. In Subversion, branches are merged using the svn merge command. In its simplest form, this means locating yourself in the working copy of the target branch (often, but not always, the main development trunk), and executing svn merge along with the branch you want to merge. So, here, we go to the development branch and merge the changes made on the release 1.1 branch:

Listing 8. Merging the changes

E:\tax-calculator-dev>svn merge file:///e:/svn/repos/tax-calculator/branches/release-1.1.0
--- Merging r22 through r25 into '.':
U    tax-calculator\src\com\jpt\taxcalculator\domain\TaxCalculator.java
U    tax-calculator\src\com\jpt\taxcalculator\domain\TaxRate.java

Now, if you inspect the log, you will find that Subversion has added a useful entry, including a comment concerning the merge we just performed. Just use the new "-g" option, and all will be revealed.

Listing 9. SVN logs the results

E:\tax-calculator-dev>svn log -g
------------------------------------------------------------------------
r26 | john | 2007-12-28 22:49:36 +1300 (Fri, 28 Dec 2007) | 1 line

Merged latest production fixes
------------------------------------------------------------------------
r25 | john | 2007-12-28 22:44:45 +1300 (Fri, 28 Dec 2007) | 1 line
Result of a merge from: r26

Updated the tax rate calculator module.
------------------------------------------------------------------------
r24 | john | 2007-12-28 22:44:04 +1300 (Fri, 28 Dec 2007) | 1 line
Result of a merge from: r26

Updated the tax rate calculation
------------------------------------------------------------------------
r23 | john | 2007-12-28 22:43:38 +1300 (Fri, 28 Dec 2007) | 1 line
Result of a merge from: r26

Corrected the tax rates------------------------------------------------------------------------
r20 | john | 2007-12-28 21:43:56 +1300 (Fri, 28 Dec 2007) | 1 line

Initial import
------------------------------------------------------------------------

Rinse and repeat

What you've seen so far already greatly improves on Subversion 1.4, but it gets better. Imagine we now do yet another bug fix to our production branch, shown in Listing 9.

Listing 9. Yet another bug fix

E:\tax-calculator-prod>svn commit -m "Fixed something else"
Sending        tax-calculator\src\com\jpt\taxcalculator\domain\TaxRate.java
Transmitting file data .
Committed revision 27.

Back in the main development trunk, we also need to integrate this correction. To re-merge code from a branch in Subversion 1.4, you would need to carefully select the revisions to be merged. For example, in this case, we only want to merge revisions 26 and 27. To figure this out in Subversion 1.4, you would needed to carefully study the log files and try to work out what was done, and when.

In Subversion 1.5, thanks to merge tracking, the Subversion repository already knows when you last did a merge. So, in this example all we need to do is to perform another merge from the production branch, using exactly the same options we used previously. Subversion will work out what needs to be done.

Listing 10. Subversion works out the details of a merge

E:\tax-calculator-dev>svn merge file:///e:/svn/repos/tax-calculator/branches/release-1.1.0
--- Merging r26 through r27 into '.':
U    tax-calculator\src\com\jpt\taxcalculator\domain\TaxRate.java

In other words, the merge is now repeatable -- you no longer need to run a different command each time you merge your changes from a branch into the trunk. This alone makes integrating changes from a production branch much smoother. It also makes automation and integration into the build process much easier.