This page provides some tips for the developer who is moving a change from one branch to another.

For general information on using Subversion on Apache projects, see http://www.apache.org/dev/version-control.html

Prior to Commit

These steps can be performed by any Derby contributor to establish the readiness of a change for merging to another branch. If the change merges successfully and you can run tests, etc., please comment on the JIRA that a simple svn merge works. This helps the committer looking to perform the actual merge, since they know the merge works and tests have already been run, etc.

If there are conflicts in the merge, please resolve the conflicts in your subversion view, run tests, and post a patch for a committer to review. The committer can then pick up the patch, review the differences between the original and merged versions, and commit if all is well.

Here are the steps:

Code Example

The example above was a documentation change. Below is an example of the commands for a code change, the merge of DERBY-4268 (revision 78527) from trunk to 10.5. Notice the URL is different.

During the Commit

When committing a merged change, it would be good if commit comments included the issue summary, and a brief overview of the change. This helps people who are studying the code later to avoid having to visit Jira each time. This helps when looking for changes that might have broken a test, a useful commit message can help in determining if change is likely to have broken a specific area or not.

Also, it is a good idea to include the specific revisions that you merged, and whether or not additional changes were necessary. This helps others when porting to another branch further back and helps to prevents duplicate merges by keeping a list of merged revisions in the history that a person can check against.

For example:

Mark the issue resolved only after the fix is in both the trunk and the branch. The fixin fields should be marked to match sysinfo on each of the branches where the fix was checked in, for example 10.4.0.0 and 10.3.2.2.

Branches are generally more stable than the trunk

The point of the branch is to provide a stable always-working set of code that anyone can take and make either a public release from or expect that a private release will work. So only bug fixes should go in, and a committer will usually exercise more caution when backporting a fix than for a trunk check-in.

A committer may first check in a change to the trunk and then let it sit for a few days before putting it into the branch. This means that the community gets a chance to see the change, the change gets tested against a wide variety of platforms, and there is time to run at least one full set of tests with the change against the branch. After a few days in trunk, if no new bugs have been found across all the various platforms, the committer will generally go ahead with the back port if appropriate. Note that each committer will use their experience and judgement to determine what makes sense.

MoveAChangeBetweenBranches (last edited 2009-09-20 22:12:46 by localhost)