Kohi Subversion - How to submit patches

10.22.2026

Since this project uses Subversion (SVN) instead of Git, contributions should be submitted as patch files attached to a ticket in the project's ticketing system.

A patch contains the changes you have made to the source code, allowing a maintainer to review and apply them without requiring direct write access to the repository.

1. Check Out the Source Code

Check out the project from the SVN repository:

svn checkout https://svn.kohiengine.com/svn/kohi/trunk kohi

This creates a local working copy in the kohi directory.

2. Make Your Changes

Edit the source code as needed. Test your changes and ensure they work as expected.

Check which files you have modified:

svn status

Review your changes:

svn diff

Make sure your patch contains only the changes relevant to your contribution. Avoid including generated files, build artifacts, unrelated changes, or personal configuration files.

Also ensure that your code matches the style of the code in the repo.

3. Create a Patch File

From inside your SVN working copy, run:

svn diff > my-feature.patch

This creates a patch file containing your local modifications.

If you have added new files that are not yet tracked by SVN, add them to version control first:

svn add path/to/new_file.c

Then generate the patch again:

svn diff > my-feature.patch

Note: svn add only schedules a file for addition in your local working copy. It does not commit anything to the repository. The patch will include the contents of scheduled, added files.

4. Review Your Patch

Before submitting, inspect the patch to make sure it contains the intended changes. For example, on macOS/Linux:

less my-feature.patch

On Windows you can use something like Notepad++ or VSCode to view the patch.

Verify that:

Only relevant changes are included.
No debugging code, temporary files, or unrelated modifications are present.
New files are included.
Your changes have been tested where practical.

5. Submit the Patch

Create a new ticket in the project's ticketing system, or open an existing ticket if one already covers the issue.

Include the following information:

Title: A brief description of the proposed change.
Description: Explain what the patch changes and why.
Testing: Describe any testing performed.
Patch file: Attach my-feature.patch to the ticket.

If the patch addresses an existing issue, reference the relevant ticket number.

6. Respond to Review Feedback

A maintainer will review the patch and may request changes before it is accepted.

To update your patch, make the requested changes in your working copy and regenerate the patch:

svn diff > my-feature.patch

Upload the updated patch to the ticket, making it clear that it replaces the previous version.

Once the patch has been approved, a maintainer will apply it to the repository.

Additional Notes

You do not need write access to the SVN repository to submit a patch.
Do not commit your changes to the main repository unless you have been granted the appropriate permissions (most won't be able to do this anyway).
Keep patches focused on a single feature, bug fix, or improvement whenever possible.
If you have multiple unrelated changes, submit separate patches under separate tickets.

Note: svn diff includes tracked modifications and files scheduled with svn add, but does not include untracked files that have not been added. Contributors should also be aware that binary files and certain file-property changes may not be represented as usable text patches.