Our company has recently switched version control systems to SVN using TortoiseSVN as our client to facilitate use of the agile development method. Our SVN repository has multiple branches from the trunk, one for each sprint. We usually do the “keep branch up to date with trunk and then reintegrate branch” method. However, sometimes changes in a branch need to be ported to the trunk, or to other branches! (like bug fixes). We have a bugfixes branch that is constantly in development (and I would like to keep it a branch if possible, so the trunk can stay “pure”).
If I merge a range of revisions from branch to trunk periodically and then re-integrate branch to trunk when our set of bugfixes is done, will this work? I don’t want to double merge things. Would it be better to never do reintegration merges instead and just keep doing range of revisions? We are using SVN 1.6.
Yes, that it will work.
Since you are using Subversion 1.6, as long the svn:mergeinfo property is not tampered with, Subversion will keep track of what changes have already been merged and merge only those changes that have not.
You can do either one. But I would recommend doing reintegration merges unless you are moving patches or hot-fixes into trunk or another branch.
One note about patches or hot-fixes when merge from branch to branch: Be careful if the hot-fix or patch has new objects (files and/or directories). Sometimes those can cause tree-conflicts which can be painful to merge or reintegrate after a branch is released, moved into trunk and the other branch is then updated from trunk. Subversion 1.6.x and related clients handle this during the merge process, but older clients do not.