Subversion Merge Plugin

Skip to end of metadata
Go to start of metadata

This plugin automates feature/personal branch workflow on Jenkins by providing one-click branching/rebasing/integration or automated rebasing/integration.

Plugin Information

Plugin ID svnmerge Changes In Latest Release
Since Latest Release
Latest Release
Latest Release Date
Required Core
2.5 (archives)
Jan 09, 2015
subversion (version:2.5)
promoted-builds (version:2.15, optional)
Source Code
Issue Tracking
Pull Requests
Open Issues
Pull Requests
Hugues Chabot (id: hugueschabot)
Usage Installations 2014-Nov 992
2014-Dec 986
2015-Jan 1020
2015-Feb 1008
2015-Mar 1102
2015-Apr 1097
2015-May 1110
2015-Jun 1177
2015-Jul 1162
2015-Aug 1129
2015-Sep 1114
2015-Oct 1151

For general discussion of feature branches in Subversion, see Online subversion book or articles. Feature branches allow developers to commit their changes without worrying too much about regressions, and this Jenkins plugin assists teams to deploy this more easily.


One-click feature branch setup

You can have Jenkins create a branch in Subversion and create a job for it (by copying from the trunk build job) just by one click of a button.

To do this, first enable the feature branch support in the job that currently builds the trunk by clicking "Accept Integration from Subversion feature branches." This creates an action on the left to manage/create new feature branches. From this page, you can create a branch and the job:

Alternatively, you can manually create a branch, create a job, and enable the feature branch support after the fact by clicking "This project builds a Subversion feature branch" and specifying the trunk job.

Integration status visualization

Jobs that build feature branches get two actions on the left. One shows the status of the integration, meaning what changes in the branch has already been integrated into the trunk, the revision number of the integration commit, what trunk CI job has built it, etc.

The up arrow in the build history indicates builds whose output has been integrated upstream.

One-click rebase

The other action in the project top page allows you to manually initiate the "rebase" action, which is a Subversion merge command to pull in the latest changes from the trunk into your feature branch, thereby synchronizing the branch with the trunk.

In addition to rebasing with the tip of the trunk, this UI allows you to pick arbitrary revision to rebase, in terms of the known build — for example, you can rebase with the revision that was resulted in the last stable trunk build, thereby eliminating any risk that you pick up regressions into your branch.

(This also works with the build promotion plugin and others that can define their own permalinks.)

Automatic rebase

Aside from manually performing rebase, you can also make rebase a part of the build. This can ensure that your feature branch always stay close to the trunk, thereby reducing the pain of the merge down the road.

Specifying the build to rebase to is a good way to control the frequency of the rebase. For example, imagine using the build promotion plugin on the trunk, and promote a build as "rebase point" about once a day (contingent on passing QA jobs.) Since the last "rebase point" build would only change about once a day, the automatic rebase would be no-op most of the time but only once a day.

Automatic integration

In addition to initiate integration manually, you can also make Jenkins do integration automatically. This can be used as a publisher, as seen below:

If you enable this in a project, you'll be automatically integrating with every successful build. This is useful for personal branches, where you'll keep on committing to this branch and let Jenkins verify the change before it gets integrated into the trunk.

This feature gets more interesting in combination with the build promotion. You can keep producing CI builds quickly, then use other jobs to verify its quality, and as a promotion action you can make the integration happen. This matches more closely with the typical integration workflow.


  • Automatic rebase and integration actions can be configured in the upstream job so they are automatically configured on feature branch jobs when created by the plugin.
  • You can avoid the so-called Subversion "keep-alive-dance" which triggers unnecessary builds of the feature branch by excluding the commit messages matching Rebasing with the integration commit that was just made in rev\.\d+ (see this discussion).



Version 2.5 (January 10, 2015)

Version 2.4 (December 20, 2014)

  • Add support for build parameters in Subversion URLs. (issue 24735).
  • Fix wrong revision used for upstream integration (issue 25739).
  • Add permissions for Rebase and Integrate actions (issue 25942).
  • Fix integration of promoted builds (issue 14725).
Breaking changes
New permissions for Rebase and Integration will have to be granted manually on system using matrix-based authorization.

Version 2.3 (July 15, 2014)

Version 2.2 (May 28, 2014)

  • Improved repository layout detection and customization on "New Branch" action (issue 15830, issue 22284).
  • Added option on "Automatic Rebase" action to fail the build when merge conflicts are found (issue 6851, issue 22850).

Version 2.1 (Mar 13, 2014)

  • Fix reintegration issue with HTTP protocol (issue 12495).

Version 2.0.4 (Feb 28, 2014)

Version 1.3 (Feb 21, 2014)

  • Handle feature branches in subfolder (isse 21781).
  • Added possibility to enter a commit message when creating a feature branch (issue 11012).
  • Copy "Local module directory" from upstream project when creating a feature branch (issue 11379).

Version 1.2 (Apr 14, 2012)

Version 1.1 (Oct 1, 2011)

Version 1.0 (Sep 1, 2011)

  • Initial release


plugin-scm-related plugin-scm-related Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Add Comment