Submit a Patch

Creating and submitting a patch

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:

• Always create the patch from the root of the ABS component.
• If this was a new piece of work without a Scarab issue, create a Scarab issue for it now : http://sharengo.org/scarab/issues
• Name the file <component name>.patch
• Attach the patch to the Scarab issue you were working on (do not paste its content in as a comment though). When adding the patch add a comment to the issue explaining what it does. Shortly after, someone will apply the patch and close the issue.

An example on how to create a patch from the command line:

$> cd .../pragmatic-ws/components/mda/pragmatic-uml/trunk
$> svn diff > pragmatic-uml.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 Scarab 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 Scarab> | patch -p0

If the patch is in a local file pragmatic-uml.patch
and you want to apply that use this command:

$> patch -p0 < pragmatic-uml.patch

A couple of notes:

• If you are using another tool for creating patches, make sure that the patch doesn't include absolute paths. Including absolute paths in the patch will make the useless for us as we most likely don't have the same directory structure as you.
• Make sure that you follow our code style.

Other useful Subversion commands while developing

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 svnignore
$>svn commit
#An example svnignore file:
build.xml
eclipse-build.xml
*.log*
.classpath
.project

Or you can use :

$> svn propset svn:ignore build.xml .
$> svn propset svn:ignore eclipse-build.xml .
$> svn propset svn:ignore *.log* .
$> svn propset svn:ignore .classpath .
$> svn propset svn:ignore .project .
$> svn propset svn:ignore build common
$> svn propset svn:ignore build client
$> svn propset svn:ignore build server
$> svn commit

For verify status of your local repository :

$> svn status

If you want look all status :

$> svn status --no-ignore

Submit a Patch is mentioned on: PragMaTic