...
Then, send in a patch file. This is a file which will describe all the differences between your modified code and the code in the OFBiz Subversion repository. You can create a patch file by using a command like this:
| Code Blockpanel |
|---|
|
$ svn diff applications/product > product.diff |
will give us a patch file for all your changes in the applications/product sub-directory and save it as product.diff.
If you have added new files, then use the "add" command first, then make the diff
| Code Blockpanel |
|---|
|
$ svn add applications/product/<my-file>
svn diff applications/product > product.diff |
You can also specify the exact files that you'd wish to include in your patch file, in case there are files that you have modified but do not wish to submit. For example, you can use
| Code Blockpanel |
|---|
|
$ svn status applications/product |
to see which files have been modified (they start with an "M") or added (which start with a "?").
Then do:
| Code Blockpanel |
|---|
|
$ svn diff applications/product/entity/ applications/product/script/org/ofbiz/shipment/shipment/ShipmentServices.xml > product-shipment.diff |
if you only want to make a patch file of the entity/ sub-directory and the ShipmentServices.xml file.
For consistency, please make your patch files from the OFBIZ_HOME directory (usually ofbiz/) and with relative file paths. Your patch file should have file names like:
applications/party/widget/partymgr/PartyScreens.xml
framework/webtools/config/WebtoolsErrorUiLabels.properties
and should not have file names like:
...
Make sure that the from/current revision of your local sandbox (checkout) is the current revision, or a very recent one, from the OFBiz SVN repository. The local revision can be checked by doing:
| Code Blockpanel |
|---|
|
$ svn info |
To make sure you have the most recent revision always do an SVN update before doing the patch with svn diff, something like this:
| Code Blockpanel |
|---|
|
$ svn up |
This must always be done before submitting a patch otherwise the patch just won't work. If your local sandbox is checked out from a separate SVN repository following the vendor branch pattern instead of directly from the OFBiz SVN, then you should do a vendor branch update, merge, and then local update in your sandbox before doing the svn diff to create the patch.
Next upload your patch file to your JIRA issue. Please use .patch as extension, some tools use extensions and this facilitates commiters works.
Finally, if there are several patch files already on an issue, please write a comment about which file should be used. A best practice is also to keep the same filename if a patch file is updated. Jira will take care of that and will keep (better for history) but gray deprecated files with the same filename. It's easier for commiter to see at 1st glance which file to use. You can read in 1st comment below what may happen when not using the same filename.
When a Jira issue is totaly resolved, we prefer to close the issue than to put it as resolved. There are some cases where there is a tentative resolution and you don't want to close the case because you want the reporter or someone to review and test the fix to make sure it was what was intended. If it is a simpler issue and especially if you are the reporter, then it is best to just close it right away rather than coming back to it later to close.
Why is it Taking So Long to Get My Patch into OFBiz?
...