Differences between revisions 5 and 6
Revision 5 as of 2006-03-15 17:26:55
Size: 4133
Comment: Add suggestion to check javadoc for new warnings/errors
Revision 6 as of 2009-09-20 22:11:34
Size: 4137
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
   * Otherwise, you may choose to run {{{svn update -r { DATE } }}}, using the date of the contribution of the patch. NOTE: svn is very picky about date formats. See [http://svnbook.red-bean.com/en/1.0/ch03s03.html these notes on valid date formats].    * Otherwise, you may choose to run {{{svn update -r { DATE } }}}, using the date of the contribution of the patch. NOTE: svn is very picky about date formats. See [[http://svnbook.red-bean.com/en/1.0/ch03s03.html|these notes on valid date formats]].
Line 29: Line 29:
   * possibly running some or all of the [http://svn.apache.org/repos/asf/db/derby/code/trunk/java/testing/README.htm regression test suites], as the committer deems relevant. Check that tests pass. If they do not:    * possibly running some or all of the [[http://svn.apache.org/repos/asf/db/derby/code/trunk/java/testing/README.htm|regression test suites]], as the committer deems relevant. Check that tests pass. If they do not:

Committing patches to the Derby Subversion Repository

Based on a previous document by Oyvind Bakksjo, here are a set of notes to guide Derby committers through the low-level mechanics of committing a change to Derby. These notes are best read within the larger context of the DerbyCommitProcess.

Committing contributions from others is not as straightforward as one might think. This mainly stems from the fact that there is an svn diff command, but there is no svn patch command. There are a number of things to remember; if not done carefully, you might end up doing partial commits that may break the build. This page attempts to give a recipe for safely committing code contributions.

  • Make sure you have a clean sandbox:
    • In the trunk directory, run svn status - it should not list anything. If it does, you may want to run svn revert -R . to remove all local modifications, or use/check out a different sandbox.

    • Run ant clobber.

  • Check your sandbox' svn revision with svn info.
  • Align your sandbox' svn revision with the patch's:
    • If the contributor has indicated on which revision the patch was created (with svn diff), run svn update -r REVISION.

    • Otherwise, you may choose to run svn update -r { DATE } , using the date of the contribution of the patch. NOTE: svn is very picky about date formats. See these notes on valid date formats.

    • If you think there has been no changes in the patch's area since it was contributed, you can try on the head: svn update.
  • Apply the patch in the trunk directory: patch -p0 < PATCH_FILE.

  • Make sure there were no conflicts when applying the patch. On unix, you can run find . -name "*.rej" -print. If a *.rej file is found, you should either resolve the conflict or ask the submitter to submit a new patch against the newest revision. If you omit this step, you'll still catch this problem before committing (when you compare your svn status output to the contributor's), but it's a good idea to catch this early on.

  • Run svn status, and check for AddedOrDeletedFilesInDiff.

  • By now your svn status should be equal to the contributor's. Now compare the diff by running svn diff | diff - PATCH_FILE. The diffs you see could be the following:

    • Revision numbers, if your sandbox was not aligned with the contributor's (see above)
    • Subversion file properties: You will have to set svn properties for AddedOrDeletedFilesInDiff.

    • Actual code diffs: Inspect and figure out what/why.
    • Files may be examined in different order by svn diff on your machine and the contributor's; not sure if there's anything we can do about that.

  • Update to the head with svn update. Check that there are no conflicts.
  • Build the code with ant all and ant buildjars.
  • Perform a final review of the change. Good practices to follow here include:
    • close reading of the diff,
    • exploratory testing of specific changes of interest,
    • verifying that the regression test(s) fail without the code change(s) and pass once the code changes are applied.
    • possibly running some or all of the regression test suites, as the committer deems relevant. Check that tests pass. If they do not:

      • Check the nightly/tinderbox for the same failure.
      • Verify that the failure is not caused by the patch.
    • run ant javadoc and check to see that no new warnings or errors have crept in

  • Commit the patch with svn commit. Use either --message, --file or --editor-cmd. Include the following in the commit log message:

    • The ID of the JIRA issue. Make sure you use the format DERBY-NNN so that JIRA picks it up.
    • Some text explaining what the patch does (typically snipped from the JIRA issue).
    • The contributor's name/email.
  • Notify the contributor and the community that the patch has been committed, according to the DerbyCommitProcess.

DerbyCommitHowTo (last edited 2009-09-20 22:11:34 by localhost)