Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
These instructions use outdated workflow based on svnmerge tool.
Cherry-picking is the act of applying only selected changesets to a current branch, rather than taking all possible changesets to bring the branch up-to-date.
In our case,
trunk is the authoritative source for everything that goes in a release; only under exceptional circumstances are changes made to
trunk. The general rule is that a change is made to
trunk and brought over to
This flow assumes that the needed changesets are already in
trunk; if not, you will need to commit a suitable changeset to
trunk following your usual development practices prior to using this flow.
Table of Contents
Check Out Checkpoint
You can review the changes available on
trunk to be integrated into
$ svnmerge.py avail --log -S $SVN/trunk
You can look at the diff that was applied by this revision:
$ svnmerge.py avail --diff -S $SVN/trunk -r54321
Use this information to determine the revision(s) to be applied.
Merge Revision(s) from Trunk
After selecting the revision(s), merge them into the
From within the
$ svnmerge.py merge -r54321,54123,53412 -b -S $SVN/trunk -f commit.txt
Update Release Values
ReleaseConfig has the correct release and says 'beta' or 'candidate' as appropriate, then run the
Commit Modified Checkpoint
log.file that describes the revisions you pulled over. You can use the
commit.txt returned by the merge step to help prepare the log file. Don't just reuse
commit.txt as it tends to be very verbose and hard to read.
Here's an example of a reasonable
Cherry-picked revisions from trunk because blah blah blah. From John Doe: - One item that was done by John Doe. - Another item that was done by John Doe. From Jim Smith: - Item done by Jim Smith.
Use your judgment. If all the revision(s) from John Doe were documentation, and Jim Smith fixed an important bug (and was the actual reason for the cherry-picking), the log message might be like this:
Jim Smith fixed the yadda yadda by blah blah, and the issue was deemed important enough to be brought over into the checkpoint branch on a expedited schedule toward a micro release. Also picked up documentation updates from John Doe as they have no possibility of destabilizing the release.
Then commit the result to SVN:
Determine What and Where to Announce
The sequel describes all the steps for a full-fledged beta or candidate release. This could be overkill. For example, if the change is small and has no impact on the way SCons operates (such as a fix to a regression test so that a production release may proceed), there's no reason to publish the checkpoint at all, as publishing the final release will be sufficient.
There's usually a reason for the choice of changesets to be cherry-picked, and it's important to someone. At a minimum, those interested parties should be notified. Other forms of publishing are optional, so use your judgment as to which, if any, of the following steps should be done.
Confirm Tests Succeeded
If the BuildBot display and the test run(s) are OK, then proceed below to publishing the release. If not, fix the problem in
trunk following your usual development practices and go back and start again.