This page covers how we handle branching and merging in the SCons development tree. We'll use svnmerge to keep track of what changes haven't been merged in each direction. Some of the concepts and steps below have been swiped from a pretty decent svnmerge howto created by Ken Kinder, with liberal help from our Gary Oberbrunner.
These are the SCons development branches and their intended uses.
The main code line from which SCons gets released. This currently lags patches that the mailing list discussions describe as "checked in to Subversion." The real latest-and-greatest checked-in source containing SK's patches is in branches/core. This is, however, where we check in web site changes into the www/ and scons.org/ subdirectories (for the tigris.org and scons.org web sites, respectively).
The main development branch for changes to the SCons infrastructure. This is where SK checks in most of the stuff he's working on and which gets sent for review to the scons-dev mailing list. This branch's parent is trunk.
Development branch for the packaging work that Philipp Scholl is working on as a Google Summer of Code project.
Development branch for the Big Signature Refactoring that SK has been working on since the last ice age. This branch's parent is branches/core.
A branch for work on the SCons testing infrastructure. This branch's parent is branches/core. Not very active at the moment, because most of that work is just going in right in branches/core.
The branch intended for people to check in new features to Tool modules. If you want to contribute a change here, go see the step-by-step instructions for doing so. This branch's parent is trunk.
This should take place between any branch and its parent to set up to svnmerge to handle the tracking as we go forward.
$ export SVN=http://scons.tigris.org/svn/scons $ cd my_working_directory/trunk $ svn cp $SVN/trunk $SVN/branches/new_branch $ svn commit $ cd .. $ svn co $SVN/branches/new_branch $ cd new_branch $ svnmerge init -f commit.txt $SVN/trunk $ cd ../../trunk $ svnmerge init -f commit.txt $SVN/branches/new_branch $ svn commit -F commit.txt && rm commit.txt $ cd ../branches/new_branch $ svn commit -F commit.txt && rm commit.txt
You can actually do both the svnmerge init and svn commit on one branch (in one directory) and then do both on the other branch, but doing it this way makes both of them end up with the same revision number in the svnmerge property, which is nice and symmetric.
This brings a branch in sync with the latest changes that have made it into the trunk for release (usually by being promoted from other branches, we typically don't do work directly on the trunk).
$ export SVN=http://scons.tigris.org/svn/scons $ cd my_working_directory/new_branch $ svn up $ svnmerge avail -b -S $SVN/trunk -l $ svnmerge merge -b -S $SVN/trunk -f commit.txt $ svn resolved . $ svn diff $ python runtest.py -a $ svn commit -F commit.txt && rm commit.txt
The svn resolved . is there because there may be a conflict on the svnmerge-integratedproperty that's attached to the directory to track what changes have or have not already been merged from the trunk.
This promotes the branch changes into the trunk.
Note that you should
$ export SVN=http://scons.tigris.org/svn/scons $ cd my_working_directory/trunk $ svn up $ svnmerge avail -b -S $SVN/branches/new_branch -l $ svnmerge merge -b -S $SVN/branches/new_branch -f commit.txt $ svn resolved . $ svn diff $ python runtest.py -a $ svn commit -F commit.txt && rm commit.txt
The svn resolved . is there because there may be a conflict on the svnmerge-integratedproperty that's attached to the directory to track what changes have or have not already been merged from the development branch.