Question

When I want to add a new feature to our project, I create a branch for that feature. Whenever the feature is complete, I merge the branch back in the trunk.

However, sometimes I have to solve critical bugs in the branch I’m working on. The bug-fix needs to be applied immediately, so I do the fix directly in the trunk and I commit the change.

Usually, I also need the bug to be fixed in the branch I’m working on (to avoid encountering it while I work on the branch feature), so I simply copy the fixed code from the trunk files and I paste it into the branch code to replace the buggy code.

My questions are : I there a way in SVN to update specific branch files from newer trunk files? Also, do you think there would be a proper way to address critical bugs?

EDIT : It is possible to do it with the TortoiseSVN client?

Answer 1

So, how are you doing the fix?

Are you fixing it on your feature branch and merging it to trunk?

If so:

You can specify specific revisions you want to merge into another branch. For example, if you fixed the bug in revision 1001 on the branch, you want to merge just that revision.

You may also need to use the --reintegrate flag. This is used when you merge information back to parent branch. For example, if you branch came from trunk, and you’re merging information from the branch back to the trunk, you use the --reintegrate option.

If you’ve already modified the code on trunk, and simply want to record the merge, you can use the --record-only option. This records that the change on the branch was incorporated into the trunk, but doesn’t actually perform the merge.

---

Or, was there a fix on the trunk, and you want that in your feature branch.

If so, you want to use the normal merge syntax. In fact, you should be merging early and often from the trunk to your branch, so you have the latest code on your feature branch.

Again, if you manually applied the patch to your feature branch, do an svn merge but use the --record-only option. This lets Subversion mark the fix as merged into the branch, but doesn’t actually preform a merge. This prevents a subsequent merge from trying to fix your fix.

The whole purpose of a feature branch isn’t to allow you to go off into a cave and program, but to prevent a feature from affecting the build while the feature is in an unstable state. I discourage feature branches. I want developers to be careful and make small changes in order to make sure the build is still good. I also want their development to be visible to the whole team. If you make a branch from trunk, then merge the code back into the trunk, you don’t see the history on the branch with svn log unless you also do --use-merge-history, and then the log gets a bit messy.

Whenever you create a branch, you end up with merging issues — especially if the branch is a convergent branch like a feature branch. The developer has to constantly merge the trunk into their branch, and then attempt to merge their work back into the trunk. Although, in theory, the whole merge from branch to trunk should be a simple copy (if the developer has been keeping their branch up to date), we usually end up with a bunch of merge conflicts.

The only time I’ll okay a feature branch is if the work on it will affect the ability of the code to be built and tested. Even adding a major new feature rarely does this if done carefully (as it should). Feature branching is usually reserved when the code is being refactored or a central part of the foundation of the code is being reworked.