converted to 1.6 markup
|No differences found!|
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:
- First, check out the branch in question
- Next, determine which revision(s) you wish to move. This information should be available in the JIRA notes for the issue that you're working on. The main Comments section is below the Description box. To the right of "Comments" there is a "Subversion Commits" link, which brings up the svn info.
- For purposes of this page, we'll use the example of DERBY-1207, where the changes to the trunk were made as revision 393540, and we wish to merge those changes to branch 10.1:
svn merge -r 393539:393540 https://svn.apache.org/repos/asf/db/derby/docs/trunk/
- review the results that you got, build them, and run the necessary tests.
- In some cases, it is possible that a merge has conflicts in some files. In that case, please resolve the changes in the files that have the conflict and then generate a patch. When merging and creating a new patch for a branch, if you see a "A + " in svn status, this indicates only property change for new files. The contents of the new files are not added to the patch file. One way to include the new files is, to do a "svn revert" and "svn add" for the "A + " files.
- Note that you can also merge a range of fixes. Depending on what you are doing, you may have one or several revisions to merge.
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.
cd derby/10.5 (the source root for your 10.5 checkout)
svn merge -r 785270:785271 https://svn.apache.org/repos/asf/db/derby/code/trunk
- build and run tests.
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.
- DERBY-324 AES encryption test fails on Solaris 10
- Merged by svn merge -r 232996:232997 ../trunk/
- Simple merge with no conflicts; no additional changes were necessary.
- Originally submitted by Olav Sandstaa
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.