Re: [boost] Updated Development and Release Practices for 1.35.0

From: Frank Birbacher (bloodymir.crap_at_[hidden])
Date: 2007-08-29 10:17:09

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_at_branch-rev trunk_at_HEAD to your branch_at_HEAD and
immediately (without new commits to trunk) merge the range trunk_at_HEAD to
branch_at_HEAD to trunk_at_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