Question

How best to work with a service pack branch

3

I have a mainline and a service pack branch. When the ServicePack is released, I merge the service pack branch back to the mainline. It can be that I have made hotfixes to the mainline which are not in the servicepack branch. For the next service pack I want to continue to use the same service pack branch so that I don't need a branch for every service pack, but I need the hotfixes in that branch. How can I make sure that the service pack branch at that point is again an exact copy of the mainline? Or should I create a new service pack branch with for example a version number?

asked 2012-10-25

Frans Verschoor (FraternIT)

2 answers

0

As far I know the hotfixes can be merged to the service pack. But that can be confusing, better get to one point (all hotfixes and new functionality) with an official release and start a new service branch from there.

answered 2012-10-25

Chris de Gelder

Achiel · Accepted Answer · 2012-10-26

What's generally done (and what we do during the development of the cloudportal) is the following:

We have a master (trunk, I use these two names interchangeably), branches and tags, obviously. Trunk always represents what's running in production and should always be releasable (considering it should already have been released at some point in time).

Whenever we develop features, we do that in separate branches. The tricky part comes when we want to release, as this may contain zero, one or more feature branches. We branch again from master into a "release" branch. This branch will eventually end up in production. Then we either perform small fixes (in the case of zero new features) and/or merge the changes from the features branches to this release branch. Old merged branches are deleted (it's SVN anyway, so going back should never be a problem).

We then stage & test this release branch, determine whether it's production ready and then put it into production. Release branch is merged back intro trunk and deleted, as it doesn't represent anything anymore.

That being said, that doesn't completely answer your question. You want changes from an upstream branch in your feature branch. So let's say I'm developing some major feature and in the meantime, someone else has released a new version and merged back into trunk. While you 'could' merge those changes directly back into your branch (trunk -> feature-branch) SVN doesn't handle these cases particularly well and can possibly completely fuck up your svn:mergeinfo property. What I prefer to do is rebranch from the current stable trunk (containing the fixes you want), rename my feature branch to something like feature-branch-old and then merging those changes to the new branch. Then delete feature-branch-old and continue developing in the new branch.