db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "DerbyCommitHowTo" by BryanPendleton
Date Sat, 04 Mar 2006 00:28:48 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:
http://wiki.apache.org/db-derby/DerbyCommitHowTo

------------------------------------------------------------------------------
  
  Oyvind Bakksjo compiled this 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. 
+ 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. 
@@ -21, +21 @@

     * 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.
+    * 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.
-  * Run tests if you are not confident that the contributor's/reviewer's actions are sufficient.
Check that tests pass. If they do not:
+  * 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 [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:
-    * Check the nightly/tinderbox for the same failure.
+      * Check the nightly/tinderbox for the same failure.
-    * Verify that the failure is not caused by the patch.
+      * Verify that the failure is not caused by the patch.
   * Commit the patch with {{{svn commit}}}. Use either {{{--message}}}, {{{--file}}} or {{{--editor-cmd}}}.
Include the following in the commit 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).

Mime
View raw message