0

I work in a development team that uses SVN. We keep a stable and releasable trunk at all times. All development is done on branches and is then merged to trunk when it is ready for release. If something needed to be viewed/tested before it was merged to trunk, we could deploy that branch (what might be called a feature branch) to a dev environment, where other developers and/or project managers could see it. This works well most of the time. What it doesn't work well for is when we have multiple different branches that are part of the same release cycle but not necessarily related to each other, which all need to be approved before they can be merged to the trunk all during the same period. What we'd considered doing is merging them all to a combined release branch. The problem then is that if only a portion of the branches merged are approved for release we'd need to redo the merge without those branches before we go to trunk. We'd basically have to do the merge twice - once to the dev or feature branch, and then possibly a second time to get the approved and releasable branches merged to trunk.

Is there a better way of doing this? I feel like we may run into problems if we merge from the individuals branches to a feature branch but then later again merge those individual branches to trunk. Am I right in thinking that or is this not a problem?

natealvar
  • 23
  • 1
  • 5

2 Answers2

1

Following on from Aphillippe's suggestion, you could go a step further and create release branches from the trunk that are then tagged for each individual patch release.

This approach allows any live defects to be fixed on the release branch in isolation from the trunk (these fixes should be merged back to the trunk). The isolation enables clients to get defect fixes without having to upgrade to the latest version of your software - this can save them from the potentially substantial testing time that would be associated with a "full" upgrade.

Community
  • 1
  • 1
Michael Arnell
  • 1,008
  • 1
  • 9
  • 16
  • This is similar to what we do now. We don't release code to clients, we release to a live web application, but I understand that the approach would still apply. The issue I'm having is testing and scheduling the merger of those such branches to the trunk and working with them on the branches in a development environment. – natealvar Apr 16 '12 at 02:33
0

Isn't this what Tags are for?

Branch off while working on individual features. Merge them all back into trunk for testing. When testing is complete, bugs have been fixed and it's ready for release, tag the trunk. Then you have a tag per release.

I don't really understand the need to have only releasable code in the trunk. Surely it's almost impossible to never have unreleaseable code in the trunk (if you forgive the double negative).

Aphillippe
  • 655
  • 6
  • 14
  • We could utilize tags for the last stable release rather than our current tactic - but both are valid. Neither would work better or worse for the issue I'm having now, I believe. Even if we did commit to trunk as a standard we still would prefer not to commit the branches to the trunk until they were schedule for release. For example, if branch A and B are merged to trunk but branch B is not approved for launch, then we'd have to reverse the branch B merge from the trunk to get branch A live. – natealvar Apr 16 '12 at 02:23