Hi! David Abrahams schrieb:
If you've been on a branch for a while, merge trunk -> branch and test locally before merging branch -> trunk, so the chance of new developments breaking the build when you merge to trunk is minimized.
Now, with all the merging one important information is missing. The part "merge your branch to the trunk" does not cover all neccessary information: a merge envolves _three_ "points" (point = location with revision number in svn). You can start a branch, develop in it, merge the range trunk@branch-rev trunk@HEAD to your branch@HEAD and immediately (without new commits to trunk) merge the range trunk@HEAD to branch@HEAD to trunk@HEAD. Then you need to convey the revision number "HEAD" for further merges "trunk -> branch". This is what Sebastian Redl is warning about in the thread "[SVN] Repository branches/libs experiments" (started on 08/25/07). I'm quoting him here: <QUOTE> One thing that is important to distinguish is release branches (the state of a major release, for bugfixing and point releases) and development branches (sandboxes for developing stuff). You can merge trunk changes over to release branches (and vice versa, if a bug is fixed on the release branch first), but you must never merge trunk changes to development branches! The changes from these merges would be picked up by the diffing of the branch's initial and final states. This means that the merging would try to apply changes to the trunk that were already made, hopelessly confusing the merger and making the merging very, very difficult. So don't do it. If you've spent so much time on a development that your patch is hopelessly out of date, you do this: create another branch based on the most recent trunk state, merge the changes of your original branch to this new one as you would merge them to the trunk, then fix everything that doesn't work. Then, merge the changes done on this new branch to the trunk. </QUOTE> To K.I.S.S. one should not merge the trunk changes into his development branch. I agree on this unless we employ svnmerge ( http://trac.edgewall.org/wiki/SvnMerge ). And I actually would prefer svnmerge which is likely to become part of svn in release 1.5. Frank