TortoiseSVN / Subversion-分支到主干的定期合并

Question

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.

Answer 1

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?

Yes, that it will work.

I don't want to double merge things.

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.

Would it be better to never do reintegration merges instead and just keep doing range of revisions?

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.

Answer 2

Two questions:

• Are you running multiple unrelated sprints in a single release cycle?

• Do you tag releases to last released production versions on completion of every release cycle?

If you answered yes to the first question, it makes sense for multiple branches and periodic merges from branches to trunk. If you tag releases periodically or every release, it might make it redundant to run branches at all and have trunk as the "bleeding edge" development version, including bugfixes. YMMV.