db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: Derby commit process
Date Thu, 02 Mar 2006 11:50:45 GMT
>>>>>>>>>>>> Bernt M. Johnsen wrote (2006-02-28 22:49:12):
> > 4) I seem to remember Oyvind (Oyvind.Bakksjo@Sun.COM) had  posted some
> > tips for committers/reviewers at one point , but I can't seem to find
> > them in the archives now.
> I'll see if I can find something.

I found √ėyvinds commit description:

 Committing patches to the Derby Subversion Repository

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 (lack of symmetry - see
this and this Subversion issue). 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. 

   1. Make sure you have a clean sandbox:

         1. 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

         2. Run ant clobber.

   2. Check your sandbox' svn revision with svn info.

   3. Align you sandbox' svn revision with the patch's.

         1. If the contributor has indicated on which revision the
            patch was created (with svn diff), run svn update -r

         2. 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 and scan down for
            valid date formats. 

         3. 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. 

   4. Apply the patch in the trunk directory: patch -p0 < PATCH_FILE.

   5. 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. 

   6. Run svn status

   7. Newly added files will show up with ?, indicating that
      Subversion does not know anything about them. You will have to add
      these yourself using svn add. 

   8. You will have to set svn properties for added files. In
      particular for all text files. Run svn propset svn:eol-style
      native FILE(S). If you have your subversion configuration
      setting this should be done automatically. Add this list to your
      ~/.subversion/config file, as described in

   9. Now compare your sandbox to the contributor's: run svn status |
      diff - CONTRIBUTOR'S_SVN_STATUS_FILE. This should be clean,
      except that the ordering may be different. You can overcome this
      by sorting both your own svn status output and the contributor's
      file with sort before comparing: svn status | sort >
      diff - MY_SVN_STATUS_FILE.

         1. If the svn status output was made on Windows vs. Unix, you
            may need to adjust formatting such as spacing and forward
            versus backward slashes.

         2. If the diff contains new, empty files, patch will not
            create them for you; you will have to create them yourself
            using touch FILENAME.

               1. After creating such new, empty files, you will have
                  to add them, too, with svn add.

  10. By now your svn status should be equal to the contributor's. Now
      compare the diff by running svn diff | diff - PATCH_FILE.

  11. The diffs you see could be the following:

         1. Revision numbers, if your sandbox was not aligned with the
            contributor's (see above)

         2. Subversion file properties: You will have to set svn
            properties for added files (see above). Do not
            automatically take for granted the properties in the
            contributor's patch file, he/she may have got it wrong;
            use your own judgement.

         3. Actual code diffs: Inspect and figure out what/why.

               1. 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.

  12. Update to the head with svn update. Check that there are no

  13. Build the code with ant all and ant buildjars.

  14. Run tests if you are not confident that the
      contributor's/reviewer's actions are sufficient.

         1. Check that tests pass. If they do not:

               1. Check the nightly/tinderbox for the same failure.

               2. Verify that the failure is not caused by the patch.

  15. Commit the patch with svn commit. Use either --message, --file
      or --editor-cmd

         1. Include the following in the commit message:

               1. The ID of the JIRA issue. Make sure you use the
                  format DERBY-NNN so that JIRA picks it up.

               2. Some text explaining what the patch does (typically
                  snipped from the JIRA issue).

               3. The contributor's name/email.

  16. Send out an email to let people know you have committed the

-- OyvindBakksjo - 04 Oct 2005

Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

View raw message