Subversion branching strategy

Sign in Recent Site Activity Report Abuse Print Page Powered By Google Sites.

C version number stamping with Jenkins. New Posts on howto Hereafter he can continue to do more changes on the developer stream and deliver them later.

Branching Strategies For Git and Subversion

Here's a shot description on how to implement this development branching strategy work in Subversion. Now he would like to integrate his work onto the trunk and he merges it back there.

The tricky part in Subversion is that merges are really pulls and not pushes.

Common Branching Patterns

So out-of-the-box the trunk will know what happened it pulled work from the developer branch but the developer branch hasn't got a clue, that some of the stuff was delivered onto trunk. This is a problem in Subversion.

If you were in git, Mercurial or ClearCase, these systems would internally keep track of what had happened and then development stream would immediately be ready for continued use. In Subversion on the other hand you are instructed to regard the development streams as a -now terminated - feature stream and you should abandon it and create a new one.

If the developer now continues to work on his own branch in Subversion, and he makes a new commit - say Then the next time the trunk pulls from the developer branch it will still merge all the changes from 80 through , even if the ones from 80 through 94 was already pulled once.

The solution is that every time the trunk pull from a developer branch, the developer branch must pull changes back again - the term rebase is frequently used for this operation, only it's not very logical that you should rebase a branch that just delivered. But if you can accept this as an odd feature in Subversion and just live with it - it actually works.

As you can see in the picture to the right. If you do not "rebase" Fig.

A you will end up with delivering the entire change set every time, and effectively merge changes that has already been merged. But if you do the rebase Fig.

B - that is merge trunk to the developments branch immidiately, then subversion is able to know the difference. Create a new development branch off trunk and swith your work space svn cp -m "dev branch" svn: Navigation home Bazaar Bug report BullsEye Coverage C version number stamping with Jenkins ClearCase Fogbugz FxCop Google Apps Jenkins Maven Mercurial New Posts on howto QR Codes Real Simple Syndication Subversion TestComplete 8 Ubuntu VMware.

You simply merge trunk into the development branch before you continue working.