When you have either completed an issue or just want some feedback on the work you have done, create a patch and attach the patch to the issue in question. We have a couple of guidelines when creating patches:
An example on how to create a patch from the command line:
$ svn diff > CONTINUUM-1234.patch
If you are picking up an issue with a existing patch attached to the issue you can apply the patch to your working directory directly from JIRA like this. The wget and patch commands will only be available if you are on a UNIX platform or using Cygwin on Windows.
$ wget -O - -q <URL to the patch from JIRA> | patch -p0
If the patch is in a local file CONTINUUM-1234.patch and you want to apply that use this command:
$ patch -p0 < CONTINUUM-1234.patch
A couple of notes:
If you've done a chunk of work and you would like ditch your changes and start from scratch use this command to revert to the original checkout:
$ svn revert -R .
The -R argument means that the command will recurse down all directories and revert all changes.
Before committing code to the Subversion repository we always set the svn:ignore property on the directory to prevent some files and directories to be checked in. We always exclude the IDE project files and the target/ directory. Instead of keeping all of the excludes in mind all the time it's useful to put them all in a file and reference the file with the -F option:
$ svn propset svn:ignore -F ~/bin/svnignore .
An example svnignore file:
target *~ *.log .classpath .project *.ipr *.iws *.iml
There are a number of criteria that a patch will be judged on:
Above all, don't be discouraged. These are the same requirements the current committers should hold each other to as well. And remember, your contributions are always welcome!
Commits should have a message that follows this template:
[issue] <<summary>> <<description>> Submitted by: <<name>>
[issue] can be omitted if there is no relevant JIRA issue, though it is strongly encouraged to create one for any non-trivial change.
summary should briefly describe the problem or intent. Often the summary from the JIRA issue will work.
description should describe what was changed, and why. This is important so that others can follow your thought process and evaluate the change.
Submitted by only needs to be included when a patch is being applied for a non-committer.
[CONTINUUM-1234] Fix X when doing Y Added a check to make sure Z is true before we decide to... This will prevent... Submitted by: Baz Bazman